From jhendrikx at openjdk.org Thu Jun 1 00:00:20 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 1 Jun 2023 00:00:20 GMT Subject: Integrated: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState In-Reply-To: References: Message-ID: On Mon, 27 Mar 2023 13:50:40 GMT, John Hendrikx wrote: > The class `PseudoClassState` is private API, but was exposed erroneously in the CSS API. Instead, `Set` should have been used. This PR corrects this. This pull request has now been integrated. Changeset: 3fa02ee9 Author: John Hendrikx URL: https://git.openjdk.org/jfx/commit/3fa02ee96a6dadbc20cacbf399a2d65df708eee1 Stats: 230 lines in 8 files changed: 100 ins; 69 del; 61 mod 8304959: Public API in javafx.css.Match should not return private API class PseudoClassState Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1070 From jhendrikx at openjdk.org Thu Jun 1 00:06:20 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 1 Jun 2023 00:06:20 GMT Subject: RFR: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values [v6] In-Reply-To: References: <484iszAUIMqb6-eJomeXxVSuEQhw_bnd57fKoPqBCOg=.3714c74f-2e43-4759-b485-3db0c878b06c@github.com> Message-ID: On Wed, 31 May 2023 20:03:04 GMT, Michael Strau? wrote: >> John Hendrikx has updated the pull request incrementally with three additional commits since the last revision: >> >> - Remove seed >> - Add test cases for negative values >> - Add copyright headers > > modules/javafx.graphics/src/main/java/com/sun/javafx/scene/layout/ScaledMath.java line 31: > >> 29: * Math functions which deal with rounding scaled values. >> 30: */ >> 31: public class ScaledMath { > > If you want, you could make this class final and give it a private constructor. But since this is not public API, it probably doesn't matter all that much. Thanks, I'll leave it as-is for now. > modules/javafx.graphics/src/test/java/test/javafx/scene/layout/RegionTest.java line 1323: > >> 1321: >> 1322: double[] scales = new double[] {1.0, 1.25, 1.5, 1.75, 2.0, 1.374562997, 20.0}; >> 1323: Random random = new Random(); > > In my opinion, using a fixed seed would have been preferable here. I agree with you, but I'll like to leave it now as-is as it was already discussed, and it won't make much of a difference at this point as there are better tests in place directly on `ScaledMath`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1118#discussion_r1212429858 PR Review Comment: https://git.openjdk.org/jfx/pull/1118#discussion_r1212428408 From jhendrikx at openjdk.org Thu Jun 1 00:06:22 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 1 Jun 2023 00:06:22 GMT Subject: Integrated: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 10:11:42 GMT, John Hendrikx wrote: > Region has floor and ceiling functions that ensure that calling them twice in a row will yield the same result: > > ceil(x) = ceil(ceil(x)) > > However, due to use of a constant `EPSILON` which is added/subtracted before doing the rounding, this only works for small numbers (in the range of 0-50 approximately). For larger values and scales, rounding errors can easily occur. This is visible as artifacts on screen where controls are a pixel wider than they should be. > > The use of the `EPSILON` constant is incorrect, as its value depends on the magnitude of the value in question (as magnitude increases, the fractional precision decreases). > > The Math class offers the function `ulp` that should be used here. It represents the smallest possible change in value for a given double. > > Extending the existing test case `snappingASnappedValueGivesTheSameValueTest` to use larger magnitude numbers exposes the problems. This pull request has now been integrated. Changeset: 7825137d Author: John Hendrikx URL: https://git.openjdk.org/jfx/commit/7825137dc2d9f8d4ebc50c864522fae990cadc71 Stats: 418 lines in 7 files changed: 339 ins; 44 del; 35 mod 8306990: The guarantees given by Region's floor and ceiling functions should work for larger values Reviewed-by: angorya, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/1118 From jhendrikx at openjdk.org Thu Jun 1 00:10:12 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 1 Jun 2023 00:10:12 GMT Subject: RFR: 8299756: Minor updates in CSS Reference [v3] In-Reply-To: References: Message-ID: On Wed, 31 May 2023 23:14:21 GMT, Andy Goryachev wrote: >> Minor fixes and addition of missing sections: >> >> - The 'system' font is missing from the list of generic font family names in the section. ? >> - Explicitly add text color property -fx-fill to Text section, so as not to confuse with Labeled -fx-text-fill ? >> - TextFlow section is missing, properties: -fx-text-alignment, -fx-line-spacing, -fx-tab-size ? >> - Text: missing -fx-line-spacing, -fx-bounds-type ? >> - -fx-focus-traversable is in Node and not in Control (though there is some relevant comment) - keep as is. ? >> - Node: broken link to 'Control' (sic, not Controls) in "... see Controls for details" ? >> - Missing <text-bounds-type> type ? > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > pane Marked as reviewed by jhendrikx (Committer). modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 1598: > 1596:
    > 1597:
  • logical: The logical bounds are based on font metrics information. > 1598: The width is based on the glyph advances and the height on the ascent, descent, and Should this perhaps be "of" ? Suggestion: The width is based on the glyph advances and the height of the ascent, descent, and modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 1599: > 1597:
  • logical: The logical bounds are based on font metrics information. > 1598: The width is based on the glyph advances and the height on the ascent, descent, and > 1599: line gap. Except for the last line which does not include the line gap. I think this may flow better: Suggestion: line gap, except for the last line which does not include the line gap. ------------- PR Review: https://git.openjdk.org/jfx/pull/1144#pullrequestreview-1454348384 PR Review Comment: https://git.openjdk.org/jfx/pull/1144#discussion_r1212431893 PR Review Comment: https://git.openjdk.org/jfx/pull/1144#discussion_r1212432358 From mhanl at openjdk.org Thu Jun 1 09:42:18 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 1 Jun 2023 09:42:18 GMT Subject: RFR: 8299756: Minor updates in CSS Reference [v3] In-Reply-To: References: Message-ID: <8PqyIO7pxL3yAp26MCfWNCg8PGV_tl_7o3r6lHf6V_Y=.f892c7b8-baeb-40c4-8eb1-17bcc4d75f36@github.com> On Tue, 30 May 2023 15:42:51 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 367: >> >>> 365:
>>> 366: >>> 367:
  • Controls >> >> We should consider leaving this as `href` and adding a `Controls` heading instead. >> It should be here: >> ![image](https://github.com/openjdk/jfx/assets/66004280/be1134e5-91df-4650-b56d-3f6ecd7cc18a) >> As it is for all other headers e.g. `Nodes` >> ![image](https://github.com/openjdk/jfx/assets/66004280/17eba5ee-9804-4452-aaf2-b8448a9d4cb4) > > you are right You need to add a `Controls` headline still. `

    Nodes

    ` It should be above the `javafx.scene.control` row. Then the `href` will work and is consistent with the other headers. ![image](https://github.com/openjdk/jfx/assets/66004280/fd80afd3-5b12-401d-a9f2-d14f123927f6) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1144#discussion_r1212881824 From thiago.sayao at gmail.com Thu Jun 1 10:28:29 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 1 Jun 2023 07:28:29 -0300 Subject: IME Attributes Message-ID: Hi, View.java has those attributes: @Native public final static byte IME_ATTR_INPUT = 0x00; @Native public final static byte IME_ATTR_TARGET_CONVERTED = 0x01; @Native public final static byte IME_ATTR_CONVERTED = 0x02; @Native public final static byte IME_ATTR_TARGET_NOTCONVERTED = 0x03; @Native public final static byte IME_ATTR_INPUT_ERROR = 0x04; I will investigate and learn by myself, but if anyone has information about those I'll appreciate it. It's for: https://github.com/openjdk/jfx/pull/1080 -- Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Jun 1 13:23:20 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 1 Jun 2023 13:23:20 GMT Subject: RFR: 8299756: Minor updates in CSS Reference [v3] In-Reply-To: References: Message-ID: On Wed, 31 May 2023 23:14:21 GMT, Andy Goryachev wrote: >> Minor fixes and addition of missing sections: >> >> - The 'system' font is missing from the list of generic font family names in the section. ? >> - Explicitly add text color property -fx-fill to Text section, so as not to confuse with Labeled -fx-text-fill ? >> - TextFlow section is missing, properties: -fx-text-alignment, -fx-line-spacing, -fx-tab-size ? >> - Text: missing -fx-line-spacing, -fx-bounds-type ? >> - -fx-focus-traversable is in Node and not in Control (though there is some relevant comment) - keep as is. ? >> - Node: broken link to 'Control' (sic, not Controls) in "... see Controls for details" ? >> - Missing <text-bounds-type> type ? > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > pane Can you add a new "Controls" section header? At the same time you can evaluate the suggestions from @hjohn modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 1700: > 1698:   > 1699: The default value for controls is true, although there are some exceptions. > 1700: See Control for details. As noted by @Maran23 , this change should be reverted and a new section header for "Controls" should be added. ------------- Changes requested by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1144#pullrequestreview-1455462317 PR Review Comment: https://git.openjdk.org/jfx/pull/1144#discussion_r1213144300 From kcr at openjdk.org Thu Jun 1 13:23:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 1 Jun 2023 13:23:21 GMT Subject: RFR: 8299756: Minor updates in CSS Reference [v3] In-Reply-To: <8PqyIO7pxL3yAp26MCfWNCg8PGV_tl_7o3r6lHf6V_Y=.f892c7b8-baeb-40c4-8eb1-17bcc4d75f36@github.com> References: <8PqyIO7pxL3yAp26MCfWNCg8PGV_tl_7o3r6lHf6V_Y=.f892c7b8-baeb-40c4-8eb1-17bcc4d75f36@github.com> Message-ID: On Thu, 1 Jun 2023 09:39:18 GMT, Marius Hanl wrote: >> you are right > > You need to add a `Controls` headline still. > `

    Nodes

    ` > It should be above the `javafx.scene.control` row. > Then the `href` will work and is consistent with the other headers. > > ![image](https://github.com/openjdk/jfx/assets/66004280/fd80afd3-5b12-401d-a9f2-d14f123927f6) @Maran23 I see what you are saying now, and you are right. The change to the link should be reverted, and a new heading added as you suggest. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1144#discussion_r1213142525 From karthik.p.k at oracle.com Thu Jun 1 13:41:41 2023 From: karthik.p.k at oracle.com (Karthik P K) Date: Thu, 1 Jun 2023 13:41:41 +0000 Subject: CFV: New OpenJFX Committer: Lukasz Kostyra In-Reply-To: <9f7d2742-0b71-d05d-dedd-ca96ac4267b3@oracle.com> References: <9f7d2742-0b71-d05d-dedd-ca96ac4267b3@oracle.com> Message-ID: Vote : YES Regards, Karthik From: openjfx-dev on behalf of Kevin Rushforth Date: Wednesday, 24 May 2023 at 5:18 PM To: openjfx-dev , Lukasz Kostyra Subject: CFV: New OpenJFX Committer: Lukasz Kostyra I hereby nominate Lukasz Kostyra [1] to OpenJFX Committer. Lukasz is a member of the JavaFX team at Oracle who has contributed 12 commits [2] to OpenJFX. Votes are due by June 7, 2023 at 12:00 UTC. Only current OpenJFX Committers [3] 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 [4]. Nomination to a project Committer is described in [5]. Thanks. -- Kevin [1] https://openjdk.org/census#lkostyra [2] https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Lukasz%20Kostyra%22&type=commits [3] https://openjdk.org/census#openjfx [4] https://openjdk.org/bylaws#lazy-consensus [5] https://openjdk.org/projects#project-committer -------------- next part -------------- An HTML attachment was scrubbed... URL: From sykora at openjdk.org Thu Jun 1 15:00:18 2023 From: sykora at openjdk.org (Joeri Sykora) Date: Thu, 1 Jun 2023 15:00:18 GMT Subject: RFR: 8308308: Update to Visual Studio 2022 version 17.5.0 on Windows [v2] In-Reply-To: References: Message-ID: On Tue, 30 May 2023 19:10:08 GMT, Kevin Rushforth wrote: >> Update the compiler on Windows to Visual Studio 2022 17.5.0. This provides the needed C++20 support for the next WebKit update. >> >> On Windows, the existing WebKit 615.1 build fails with Visual Studio 2022 17.5.0 -- see [JDK-8303748](https://bugs.openjdk.org/browse/JDK-8303748). The solution for the failure is to compile 615.1 using the C++20 flag for Windows (we will use this flag on all platforms for the next WebKit update). The fix for that bug is necessarily included in this PR, since the two fixes as interdependent. > > Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge remote-tracking branch 'upstream/master' into 8308308-vs2022-17.5.0 > - 8308308: Update to Visual Studio 2022 version 17.5.0 on Windows > - enable c++20 for windows and c++17 for other platforms We still used an older version of cmake and updating it to 3.22.3 fixed the issue. Everything works fine now. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1142#pullrequestreview-1455691681 From kcr at openjdk.org Thu Jun 1 15:06:19 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 1 Jun 2023 15:06:19 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v13] In-Reply-To: References: Message-ID: On Sat, 20 May 2023 16:17:50 GMT, Thiago Milczarek Sayao wrote: > About the `testAnchorRight` test: I know what happened, it's the focus shadow of the button `topLeft` - it was the first child of the AnchorPane, so it got the focus and hence the difference in the value. Moving it in the Scene graph fixed it (because it does not get the primary focus). This means that there will be a sometimes-noticeable difference in behavior between JavaFX 19 (before the fix for [JDK-8296621](https://bugs.openjdk.org/browse/JDK-8296621)) and JavaFX 21 (after this fix for [JDK-8306121](https://bugs.openjdk.org/browse/JDK-8306121)). I don't think this is a problem, but I'd like to take a closer look. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1572228570 From angorya at openjdk.org Thu Jun 1 15:34:20 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Jun 2023 15:34:20 GMT Subject: RFR: 8299756: Minor updates in CSS Reference [v3] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 13:19:34 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> pane > > modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 1700: > >> 1698:   >> 1699: The default value for controls is true, although there are some exceptions. >> 1700: See Control for details. > > As noted by @Maran23 , this change should be reverted and a new section header for "Controls" should be added. not here - here the link should point to Control. @Maran23 is right - the heading H2 was originally missing from the Controls section (line 3245) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1144#discussion_r1213338006 From angorya at openjdk.org Thu Jun 1 15:50:37 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Jun 2023 15:50:37 GMT Subject: RFR: 8299756: Minor updates in CSS Reference [v4] In-Reply-To: References: Message-ID: > Minor fixes and addition of missing sections: > > - The 'system' font is missing from the list of generic font family names in the section. ? > - Explicitly add text color property -fx-fill to Text section, so as not to confuse with Labeled -fx-text-fill ? > - TextFlow section is missing, properties: -fx-text-alignment, -fx-line-spacing, -fx-tab-size ? > - Text: missing -fx-line-spacing, -fx-bounds-type ? > - -fx-focus-traversable is in Node and not in Control (though there is some relevant comment) - keep as is. ? > - Node: broken link to 'Control' (sic, not Controls) in "... see Controls for details" ? > - Missing <text-bounds-type> type ? Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: controls ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1144/files - new: https://git.openjdk.org/jfx/pull/1144/files/81d0675d..f799a33d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1144&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1144&range=02-03 Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1144.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1144/head:pull/1144 PR: https://git.openjdk.org/jfx/pull/1144 From kcr at openjdk.org Thu Jun 1 15:50:38 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 1 Jun 2023 15:50:38 GMT Subject: RFR: 8299756: Minor updates in CSS Reference [v3] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 15:31:22 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 1700: >> >>> 1698:   >>> 1699: The default value for controls is true, although there are some exceptions. >>> 1700: See Control for details. >> >> As noted by @Maran23 , this change should be reverted and a new section header for "Controls" should be added. > > not here - here the link should point to Control. > > @Maran23 is right - the heading H2 was originally missing from the Controls section (line 3245) I think this link should point to the (currently missing) Controls header and not the Control class. The "details" on focusibility that this note refers to are in the package header for `javafx.scene.control`, which will be right after the Controls header once you add it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1144#discussion_r1213348787 From angorya at openjdk.org Thu Jun 1 15:50:38 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Jun 2023 15:50:38 GMT Subject: RFR: 8299756: Minor updates in CSS Reference [v3] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 15:40:14 GMT, Kevin Rushforth wrote: >> not here - here the link should point to Control. >> >> @Maran23 is right - the heading H2 was originally missing from the Controls section (line 3245) > > I think this link should point to the (currently missing) Controls header and not the Control class. The "details" on focusibility that this note refers to are in the package header for `javafx.scene.control`, which will be right after the Controls header once you add it. there is a duplicate entry for -fx-focus-traversable in Node and Control sections. I think this particular link should point to Control, where it says "Control sets the default value of the focusTraversable property to true. The default value of the focusTraversable property for the following controls is false: Accordion, Cell, Label, MenuBar, ProgressBar, ProgressIndicator, ScrollBar, ScrollPane, Separator, SplitPane, ToolBar." ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1144#discussion_r1213351987 From kcr at openjdk.org Thu Jun 1 15:50:38 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 1 Jun 2023 15:50:38 GMT Subject: RFR: 8299756: Minor updates in CSS Reference [v3] In-Reply-To: References: Message-ID: <-vmgxqXX1VsVpiw087r7d0wYYyo5hX5VszUJ_vd9sds=.1d6da86c-0fb6-495e-a5fe-76b0e9f3251c@github.com> On Thu, 1 Jun 2023 15:42:26 GMT, Andy Goryachev wrote: >> I think this link should point to the (currently missing) Controls header and not the Control class. The "details" on focusibility that this note refers to are in the package header for `javafx.scene.control`, which will be right after the Controls header once you add it. > > there is a duplicate entry for -fx-focus-traversable in Node and Control sections. I think this particular link should point to Control, where it says > > "Control sets the default value of the focusTraversable property to true. The default value of the focusTraversable property for the following controls is false: Accordion, Cell, Label, MenuBar, ProgressBar, ProgressIndicator, ScrollBar, ScrollPane, Separator, SplitPane, ToolBar." Although... the information is also repeated in the Control class, so I won't object if you want to keep your change to point there. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1144#discussion_r1213355006 From angorya at openjdk.org Thu Jun 1 15:50:38 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Jun 2023 15:50:38 GMT Subject: RFR: 8299756: Minor updates in CSS Reference [v3] In-Reply-To: <-vmgxqXX1VsVpiw087r7d0wYYyo5hX5VszUJ_vd9sds=.1d6da86c-0fb6-495e-a5fe-76b0e9f3251c@github.com> References: <-vmgxqXX1VsVpiw087r7d0wYYyo5hX5VszUJ_vd9sds=.1d6da86c-0fb6-495e-a5fe-76b0e9f3251c@github.com> Message-ID: On Thu, 1 Jun 2023 15:45:00 GMT, Kevin Rushforth wrote: >> there is a duplicate entry for -fx-focus-traversable in Node and Control sections. I think this particular link should point to Control, where it says >> >> "Control sets the default value of the focusTraversable property to true. The default value of the focusTraversable property for the following controls is false: Accordion, Cell, Label, MenuBar, ProgressBar, ProgressIndicator, ScrollBar, ScrollPane, Separator, SplitPane, ToolBar." > > Although... the information is also repeated in the Control class, so I won't object if you want to keep your change to point there. pushed the change, try it now. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1144#discussion_r1213356043 From kcr at openjdk.org Thu Jun 1 16:34:13 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 1 Jun 2023 16:34:13 GMT Subject: RFR: 8299756: Minor updates in CSS Reference [v4] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 15:50:37 GMT, Andy Goryachev wrote: >> Minor fixes and addition of missing sections: >> >> - The 'system' font is missing from the list of generic font family names in the section. ? >> - Explicitly add text color property -fx-fill to Text section, so as not to confuse with Labeled -fx-text-fill ? >> - TextFlow section is missing, properties: -fx-text-alignment, -fx-line-spacing, -fx-tab-size ? >> - Text: missing -fx-line-spacing, -fx-bounds-type ? >> - -fx-focus-traversable is in Node and not in Control (though there is some relevant comment) - keep as is. ? >> - Node: broken link to 'Control' (sic, not Controls) in "... see Controls for details" ? >> - Missing <text-bounds-type> type ? > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > controls Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1144#pullrequestreview-1455883170 From jhendrikx at openjdk.org Thu Jun 1 17:22:13 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 1 Jun 2023 17:22:13 GMT Subject: RFR: 8299756: Minor updates in CSS Reference [v4] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 15:50:37 GMT, Andy Goryachev wrote: >> Minor fixes and addition of missing sections: >> >> - The 'system' font is missing from the list of generic font family names in the section. ? >> - Explicitly add text color property -fx-fill to Text section, so as not to confuse with Labeled -fx-text-fill ? >> - TextFlow section is missing, properties: -fx-text-alignment, -fx-line-spacing, -fx-tab-size ? >> - Text: missing -fx-line-spacing, -fx-bounds-type ? >> - -fx-focus-traversable is in Node and not in Control (though there is some relevant comment) - keep as is. ? >> - Node: broken link to 'Control' (sic, not Controls) in "... see Controls for details" ? >> - Missing <text-bounds-type> type ? > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > controls Marked as reviewed by jhendrikx (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1144#pullrequestreview-1455959835 From mhanl at openjdk.org Thu Jun 1 17:25:15 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 1 Jun 2023 17:25:15 GMT Subject: RFR: 8299756: Minor updates in CSS Reference [v4] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 15:50:37 GMT, Andy Goryachev wrote: >> Minor fixes and addition of missing sections: >> >> - The 'system' font is missing from the list of generic font family names in the section. ? >> - Explicitly add text color property -fx-fill to Text section, so as not to confuse with Labeled -fx-text-fill ? >> - TextFlow section is missing, properties: -fx-text-alignment, -fx-line-spacing, -fx-tab-size ? >> - Text: missing -fx-line-spacing, -fx-bounds-type ? >> - -fx-focus-traversable is in Node and not in Control (though there is some relevant comment) - keep as is. ? >> - Node: broken link to 'Control' (sic, not Controls) in "... see Controls for details" ? >> - Missing <text-bounds-type> type ? > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > controls LGTM ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1144#pullrequestreview-1455966703 From ambarish.rapte at oracle.com Thu Jun 1 17:33:10 2023 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Thu, 1 Jun 2023 17:33:10 +0000 Subject: CFV: New OpenJFX Committer: Lukasz Kostyra In-Reply-To: <9f7d2742-0b71-d05d-dedd-ca96ac4267b3@oracle.com> References: <9f7d2742-0b71-d05d-dedd-ca96ac4267b3@oracle.com> Message-ID: Vote: YES -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Thu Jun 1 17:33:13 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 1 Jun 2023 17:33:13 GMT Subject: RFR: 8308308: Update to Visual Studio 2022 version 17.5.0 on Windows [v2] In-Reply-To: References: Message-ID: On Tue, 30 May 2023 19:10:08 GMT, Kevin Rushforth wrote: >> Update the compiler on Windows to Visual Studio 2022 17.5.0. This provides the needed C++20 support for the next WebKit update. >> >> On Windows, the existing WebKit 615.1 build fails with Visual Studio 2022 17.5.0 -- see [JDK-8303748](https://bugs.openjdk.org/browse/JDK-8303748). The solution for the failure is to compile 615.1 using the C++20 flag for Windows (we will use this flag on all platforms for the next WebKit update). The fix for that bug is necessarily included in this PR, since the two fixes as interdependent. > > Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge remote-tracking branch 'upstream/master' into 8308308-vs2022-17.5.0 > - 8308308: Update to Visual Studio 2022 version 17.5.0 on Windows > - enable c++20 for windows and c++17 for other platforms Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1142#pullrequestreview-1455979118 From angorya at openjdk.org Thu Jun 1 17:42:14 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Jun 2023 17:42:14 GMT Subject: Integrated: 8299756: Minor updates in CSS Reference In-Reply-To: References: Message-ID: On Fri, 26 May 2023 22:26:49 GMT, Andy Goryachev wrote: > Minor fixes and addition of missing sections: > > - The 'system' font is missing from the list of generic font family names in the section. ? > - Explicitly add text color property -fx-fill to Text section, so as not to confuse with Labeled -fx-text-fill ? > - TextFlow section is missing, properties: -fx-text-alignment, -fx-line-spacing, -fx-tab-size ? > - Text: missing -fx-line-spacing, -fx-bounds-type ? > - -fx-focus-traversable is in Node and not in Control (though there is some relevant comment) - keep as is. ? > - Node: broken link to 'Control' (sic, not Controls) in "... see Controls for details" ? > - Missing <text-bounds-type> type ? This pull request has now been integrated. Changeset: 0005f656 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/0005f6569eedd045f05ebdd35bd5053515871bc1 Stats: 91 lines in 2 files changed: 85 ins; 0 del; 6 mod 8299756: Minor updates in CSS Reference Reviewed-by: kcr, jhendrikx, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1144 From kcr at openjdk.org Thu Jun 1 17:46:09 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 1 Jun 2023 17:46:09 GMT Subject: Integrated: 8308308: Update to Visual Studio 2022 version 17.5.0 on Windows In-Reply-To: References: Message-ID: On Sat, 20 May 2023 14:58:40 GMT, Kevin Rushforth wrote: > Update the compiler on Windows to Visual Studio 2022 17.5.0. This provides the needed C++20 support for the next WebKit update. > > On Windows, the existing WebKit 615.1 build fails with Visual Studio 2022 17.5.0 -- see [JDK-8303748](https://bugs.openjdk.org/browse/JDK-8303748). The solution for the failure is to compile 615.1 using the C++20 flag for Windows (we will use this flag on all platforms for the next WebKit update). The fix for that bug is necessarily included in this PR, since the two fixes as interdependent. This pull request has now been integrated. Changeset: 8fc1a256 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/8fc1a256a90fa02bbf775317de3158c81e7b950d Stats: 8 lines in 3 files changed: 4 ins; 0 del; 4 mod 8308308: Update to Visual Studio 2022 version 17.5.0 on Windows 8303748: WebKit build fails with Visual Studio 2022 17.5.0 Co-authored-by: Hima Bindu Meda Reviewed-by: arapte, sykora ------------- PR: https://git.openjdk.org/jfx/pull/1142 From kcr at openjdk.org Thu Jun 1 18:03:23 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 1 Jun 2023 18:03:23 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v14] In-Reply-To: <564SRVvbnDXoS9o0g4tAG741J6UmrNpqwcJDz8EQwW0=.2449fedf-0ae7-4380-87b6-7fcb4fdeb23a@github.com> References: <564SRVvbnDXoS9o0g4tAG741J6UmrNpqwcJDz8EQwW0=.2449fedf-0ae7-4380-87b6-7fcb4fdeb23a@github.com> Message-ID: On Sat, 20 May 2023 16:19:19 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Fix MouseEventFirerTest.java There is another failing test with this patch: DialogRepeatedShowHideTest > dialogSizeOnReShownTest FAILED java.lang.AssertionError: Dialog height should remain the same expected:<300.0> but was:<79.0> at org.junit.Assert.fail(Assert.java:89) at org.junit.Assert.failNotEquals(Assert.java:835) at org.junit.Assert.assertEquals(Assert.java:555) at test.robot.javafx.scene.dialog.DialogRepeatedShowHideTest.dialogSizeOnReShownTest(DialogRepeatedShowHideTest.java:71) It looks like this fix has reintroduced [JDK-8193502](https://bugs.openjdk.org/browse/JDK-8193502) -- the test case attached to that bug report now fails. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1572539075 From mhanl at openjdk.org Thu Jun 1 20:37:17 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 1 Jun 2023 20:37:17 GMT Subject: RFR: 8293836: Rendering performance degradation at bottom of TableView with many rows [v2] In-Reply-To: References: Message-ID: On Tue, 30 May 2023 10:39:28 GMT, Johan Vos wrote: >> Only update the VirtualFlow parameters in case the size of a cell has changed. >> >> The fixes for JDK-8298728 and JDK-8277785 introduced an unconditional recalculation in case the size of a cell is set. This recalculation is only needed in case the size of that specific cell has changed. >> Fix for JDK-8293836 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > remove newline Have one question. Otherwise looks good to me. Tested with a lot of data + with and without fixed cell size. modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 3083: > 3081: if (itemSizeCache.size() > cellIndex) { > 3082: Double oldSize = itemSizeCache.get(cellIndex); > 3083: double newSize = isVertical() ? cell.getLayoutBounds().getHeight() : cell.getLayoutBounds().getWidth(); If we have a fixed cell size set, can we save the call to get the layout bounds here? Since this is also done above in `getOrCreateCellSize` (`getFixedCellSize()`). And the layout bounds are calculated lazily, so this may improve the performance here as well. modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 3085: > 3083: double newSize = isVertical() ? cell.getLayoutBounds().getHeight() : cell.getLayoutBounds().getWidth(); > 3084: itemSizeCache.set(cellIndex, newSize); > 3085: if ((oldSize != null) && !oldSize.equals(newSize)) { Minor: Braces are not needed here modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 3088: > 3086: int currentIndex = computeCurrentIndex(); > 3087: double oldOffset = computeViewportOffset(getPosition()); > 3088: if ((cellIndex == currentIndex) && (oldOffset != 0)) { Minor: Braces are not needed here ------------- PR Review: https://git.openjdk.org/jfx/pull/1098#pullrequestreview-1456254974 PR Review Comment: https://git.openjdk.org/jfx/pull/1098#discussion_r1213648251 PR Review Comment: https://git.openjdk.org/jfx/pull/1098#discussion_r1213645083 PR Review Comment: https://git.openjdk.org/jfx/pull/1098#discussion_r1213645163 From prr at openjdk.org Thu Jun 1 20:59:17 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 1 Jun 2023 20:59:17 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v4] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <2c5EycXlOR17gt5cf_1xOE_Ncm0BBiRNugiCKFuVTe4=.e9e13776-d795-4745-9caa-8e33452f7ac1@github.com> Message-ID: On Tue, 16 May 2023 17:53:00 GMT, Andy Goryachev wrote: >> Initializing the insertion index directly with character index looks better. In this way we can avoid additional conditional logic as well. Changed code to do so. >> Added additional test case. This tests the condition present in line 430. >> I couldn't create the scenario to hit line 473. If you have any suggestions please let me know. >> >> While testing I found that `testTextFlowInsertionIndexUsingMultipleEmojis()` was failing intermittently when all the tests are run. Hence added small delay. > >> I couldn't create the scenario to hit line 473. If you have any suggestions please let me know. > > I can't seem to trigger this code path (I wonder if it's possible to hit it at all). Anyway, the code there looks correct to me, even if this condition would never happen. Assuming line 473 is the one still there today, it looks to me as if that would be reached if you had the caret on an empty line that isn't the last line. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1213669254 From prr at openjdk.org Thu Jun 1 20:59:18 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 1 Jun 2023 20:59:18 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v4] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <2c5EycXlOR17gt5cf_1xOE_Ncm0BBiRNugiCKFuVTe4=.e9e13776-d795-4745-9caa-8e33452f7ac1@github.com> Message-ID: <9H_C_l0oasD3Gw7ahd3mqSkCSp1kl3wUTsAr3Wg2iK8=.459eeb19-3569-431b-981a-0fb827e72f83@github.com> On Thu, 1 Jun 2023 20:53:07 GMT, Phil Race wrote: >>> I couldn't create the scenario to hit line 473. If you have any suggestions please let me know. >> >> I can't seem to trigger this code path (I wonder if it's possible to hit it at all). Anyway, the code there looks correct to me, even if this condition would never happen. > > Assuming line 473 is the one still there today, it looks to me as if that would be reached if you had the caret on an empty line that isn't the last line. Regarding "If we can initialize insertionIndex to a positive value, then the buggy code in HitInfo.getInsertionIndex() will never get executed, and we can remove it later (in JDK-8302511)." it seems to me that this new code has been pretty much copied from the supposedly buggy code there .. I'm not sure that code is actually buggy (comments over in that bug), rather that the instance was constructed with bad data. But maybe this code here also needs to make sure it won't cause AIOB ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1213671378 From angorya at openjdk.org Thu Jun 1 22:57:17 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Jun 2023 22:57:17 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v4] In-Reply-To: <9H_C_l0oasD3Gw7ahd3mqSkCSp1kl3wUTsAr3Wg2iK8=.459eeb19-3569-431b-981a-0fb827e72f83@github.com> References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <2c5EycXlOR17gt5cf_1xOE_Ncm0BBiRNugiCKFuVTe4=.e9e13776-d795-4745-9caa-8e33452f7ac1@github.com> <9H_C_l0oasD3Gw7ahd3mqSkCSp1kl3wUTsAr3Wg2iK8=.459eeb19-3569-431b-981a-0fb827e72f83@github.com> Message-ID: On Thu, 1 Jun 2023 20:55:33 GMT, Phil Race wrote: >> Assuming line 473 is the one still there today, it looks to me as if that would be reached if you had the caret on an empty line that isn't the last line. > > Regarding > "If we can initialize insertionIndex to a positive value, then the buggy code in HitInfo.getInsertionIndex() > will never get executed, and we can remove it later (in JDK-8302511)." > > it seems to me that this new code has been pretty much copied from the supposedly buggy code there .. > I'm not sure that code is actually buggy (comments over in that bug), rather that the instance was constructed > with bad data. > > But maybe this code here also needs to make sure it won't cause AIOB The main issue is that insertion index was not computed in the PrismTextLayout, supposedly to allow for delaying the computation until it's needed (if needed at all). A good intention, but the execution had two issues: 1. HitInfo obtained in TextFlow had its 'text' field set to null (TextFlow:204), disabling any possibility of computing the index correctly 2. The code that computed the index had an issue in that if an exception happened, it left the object in an inconsistent state, leading to other problems down the road, and more exceptions (incl. AIOB) What we did here is to compute the insertion index correctly at the source. I've also checked that in the case of an empty line the insertion index is correct in both cases (at the last line and in the middle of a document). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1213756660 From kpk at openjdk.org Fri Jun 2 07:22:21 2023 From: kpk at openjdk.org (Karthik P K) Date: Fri, 2 Jun 2023 07:22:21 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v4] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <2c5EycXlOR17gt5cf_1xOE_Ncm0BBiRNugiCKFuVTe4=.e9e13776-d795-4745-9caa-8e33452f7ac1@github.com> <9H_C_l0oasD3Gw7ahd3mqSkCSp1kl3wUTsAr3Wg2iK8=.459eeb19-3569-431b-981a-0fb827e72f83@github.com> Message-ID: <-hBaKlQFbHotzTm2Rx62yWyl_h9bZS5wIua5ITP-9Bg=.ce7cf302-974e-4c8f-8408-1a9b7a031609@github.com> On Thu, 1 Jun 2023 22:54:06 GMT, Andy Goryachev wrote: >> Regarding >> "If we can initialize insertionIndex to a positive value, then the buggy code in HitInfo.getInsertionIndex() >> will never get executed, and we can remove it later (in JDK-8302511)." >> >> it seems to me that this new code has been pretty much copied from the supposedly buggy code there .. >> I'm not sure that code is actually buggy (comments over in that bug), rather that the instance was constructed >> with bad data. >> >> But maybe this code here also needs to make sure it won't cause AIOB > > The main issue is that insertion index was not computed in the PrismTextLayout, supposedly to allow for delaying the computation until it's needed (if needed at all). A good intention, but the execution had two issues: > 1. HitInfo obtained in TextFlow had its 'text' field set to null (TextFlow:204), disabling any possibility of computing the index correctly > 2. The code that computed the index had an issue in that if an exception happened, it left the object in an inconsistent state, leading to other problems down the road, and more exceptions (incl. AIOB) > > What we did here is to compute the insertion index correctly at the source. > I've also checked that in the case of an empty line the insertion index is correct in both cases (at the last line and in the middle of a document). > Assuming line 473 is the one still there today, it looks to me as if that would be reached if you had the caret on an empty line that isn't the last line. In this case also code hits the condition in 451 as the text run is not null. >it seems to me that this new code has been pretty much copied from the supposedly buggy code there .. I'm not sure that code is actually buggy (comments over in that bug), rather that the instance was constructed with bad data. Like Andy said, since text was null in `HitInfo::getInsertionIndex()` method in the case of TextFlow, correct insertion index was not calculated. I had to use pretty much same code in PrismTextLayout as I had to consider all the cases especially the U+FE0F Variation Selector-16 characters. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1214013961 From kcr at openjdk.org Fri Jun 2 11:08:16 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Jun 2023 11:08:16 GMT Subject: RFR: 8293836: Rendering performance degradation at bottom of TableView with many rows [v2] In-Reply-To: References: Message-ID: On Tue, 30 May 2023 10:39:28 GMT, Johan Vos wrote: >> Only update the VirtualFlow parameters in case the size of a cell has changed. >> >> The fixes for JDK-8298728 and JDK-8277785 introduced an unconditional recalculation in case the size of a cell is set. This recalculation is only needed in case the size of that specific cell has changed. >> Fix for JDK-8293836 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > remove newline Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1098#pullrequestreview-1457134103 From kcr at openjdk.org Fri Jun 2 11:08:19 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Jun 2023 11:08:19 GMT Subject: RFR: 8293836: Rendering performance degradation at bottom of TableView with many rows [v2] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 20:26:33 GMT, Marius Hanl wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> remove newline > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 3085: > >> 3083: double newSize = isVertical() ? cell.getLayoutBounds().getHeight() : cell.getLayoutBounds().getWidth(); >> 3084: itemSizeCache.set(cellIndex, newSize); >> 3085: if ((oldSize != null) && !oldSize.equals(newSize)) { > > Minor: Braces are not needed here I presume you mean parentheses. True, they aren't needed, but there is no harm in leaving them. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1098#discussion_r1214233814 From kcr at openjdk.org Fri Jun 2 11:28:16 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Jun 2023 11:28:16 GMT Subject: RFR: 8306447: Adding an element to a long existing list may cause the first visible element to jump [v2] In-Reply-To: References: <97UrtekvLwi5BBpUCNUZZVFoo3H4oqaPwB8AzpXeZxA=.156a6529-5629-49cb-b95d-959d2a2b512d@github.com> Message-ID: On Sat, 29 Apr 2023 20:05:52 GMT, Johan Vos wrote: >> Calculate position of first visible element before propagating changes. >> Make sure to restore the position of said element after the changes are done. >> >> Fix JDK-8306447 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Make sure not to change index and offset when the cell count change. > Use the old cellcount when doing initial calculations, as the estimated > cell size will otherwise be wrong. > > Extend the testcase for this, by adding 9 cells instead of just 1 Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1099#pullrequestreview-1457164833 From jvos at openjdk.org Fri Jun 2 13:03:14 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 2 Jun 2023 13:03:14 GMT Subject: Integrated: 8306447: Adding an element to a long existing list may cause the first visible element to jump In-Reply-To: <97UrtekvLwi5BBpUCNUZZVFoo3H4oqaPwB8AzpXeZxA=.156a6529-5629-49cb-b95d-959d2a2b512d@github.com> References: <97UrtekvLwi5BBpUCNUZZVFoo3H4oqaPwB8AzpXeZxA=.156a6529-5629-49cb-b95d-959d2a2b512d@github.com> Message-ID: On Wed, 19 Apr 2023 13:13:45 GMT, Johan Vos wrote: > Calculate position of first visible element before propagating changes. > Make sure to restore the position of said element after the changes are done. > > Fix JDK-8306447 This pull request has now been integrated. Changeset: 1a0f6c7f Author: Johan Vos URL: https://git.openjdk.org/jfx/commit/1a0f6c7f5e131d0a40073ccfe21bb6dd0d6b2da3 Stats: 62 lines in 2 files changed: 56 ins; 1 del; 5 mod 8306447: Adding an element to a long existing list may cause the first visible element to jump Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1099 From kevin.rushforth at oracle.com Fri Jun 2 13:13:33 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 2 Jun 2023 06:13:33 -0700 Subject: Application freeze on dialog close [Mac] In-Reply-To: References: Message-ID: <3282d070-7ce9-44b2-8f09-2d46f76ce890@oracle.com> I haven't seen anything exactly like this, but it might be related to a system setting or a terminal setting (if the app is launched from a terminal) on the affected systems. You might check is whether the "Secure Keyboard Entry" setting in the Terminal is enabled on the affected macOS systems. If it is, you should see a timeout warning message when starting the application as? reported in JDK [1]. It seems possible that this setting might also cause something like you describe. If that's not the problem, then it could be some other system setting. -- Kevin [1] https://bugs.openjdk.org/browse/JDK-8283590 On 5/26/2023 3:06 AM, Craig Raw wrote: > I have multiple reports of application freeze (spinning beach ball) > when a Dialog opened with showAndWait() is closed. The application > does not recover and must be terminated with?force quit. No error > logging is produced. > > This only occurs on a Mac, and is rare, but can be consistently > reproduced on affected machines. It occurs on both Intel and M1 > chipsets. Preferring a software pipeline (prism.order=sw) does not > affect it. I am currently building with JavaFX 18 on JDK 18. > > I cannot find any related JavaFX bug report. My own Github issue is > here: https://github.com/sparrowwallet/sparrow/issues/586 > > Any assistance with further diagnosing or solving this would be > appreciated. > > Craig From jvos at openjdk.org Fri Jun 2 13:18:12 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 2 Jun 2023 13:18:12 GMT Subject: Integrated: 8293836: Rendering performance degradation at bottom of TableView with many rows In-Reply-To: References: Message-ID: On Wed, 19 Apr 2023 12:14:45 GMT, Johan Vos wrote: > Only update the VirtualFlow parameters in case the size of a cell has changed. > > The fixes for JDK-8298728 and JDK-8277785 introduced an unconditional recalculation in case the size of a cell is set. This recalculation is only needed in case the size of that specific cell has changed. > Fix for JDK-8293836 This pull request has now been integrated. Changeset: 10f41b7d Author: Johan Vos URL: https://git.openjdk.org/jfx/commit/10f41b7d1f2f53ebe2bfdb61de495bbb7290d32d Stats: 13 lines in 1 file changed: 5 ins; 6 del; 2 mod 8293836: Rendering performance degradation at bottom of TableView with many rows Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1098 From mhanl at openjdk.org Fri Jun 2 13:33:22 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 2 Jun 2023 13:33:22 GMT Subject: RFR: 8293836: Rendering performance degradation at bottom of TableView with many rows [v2] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 20:30:06 GMT, Marius Hanl wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> remove newline > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 3083: > >> 3081: if (itemSizeCache.size() > cellIndex) { >> 3082: Double oldSize = itemSizeCache.get(cellIndex); >> 3083: double newSize = isVertical() ? cell.getLayoutBounds().getHeight() : cell.getLayoutBounds().getWidth(); > > If we have a fixed cell size set, can we save the call to get the layout bounds here? > Since this is also done above in `getOrCreateCellSize` (`getFixedCellSize()`). > And the layout bounds are calculated lazily, so this may improve the performance here as well. @johanvos I still think this should be evaluated. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1098#discussion_r1214378282 From kcr at openjdk.org Fri Jun 2 13:58:16 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Jun 2023 13:58:16 GMT Subject: RFR: 8293836: Rendering performance degradation at bottom of TableView with many rows [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 13:30:38 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 3083: >> >>> 3081: if (itemSizeCache.size() > cellIndex) { >>> 3082: Double oldSize = itemSizeCache.get(cellIndex); >>> 3083: double newSize = isVertical() ? cell.getLayoutBounds().getHeight() : cell.getLayoutBounds().getWidth(); >> >> If we have a fixed cell size set, can we save the call to get the layout bounds here? >> Since this is also done above in `getOrCreateCellSize` (`getFixedCellSize()`). >> And the layout bounds are calculated lazily, so this may improve the performance here as well. > > @johanvos I still think this should be evaluated. Perhaps you could file a follow-up JBS issue? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1098#discussion_r1214414409 From duke at openjdk.org Fri Jun 2 15:43:14 2023 From: duke at openjdk.org (Eric Long) Date: Fri, 2 Jun 2023 15:43:14 GMT Subject: RFR: 8309001: Add Linux/riscv64 support to WebKit In-Reply-To: References: Message-ID: On Tue, 30 May 2023 18:29:53 GMT, Kevin Rushforth wrote: > Can you enable GitHub Actions for your personal fork to help verify that this doesn't impact builds on our core platforms? Sure, enabled. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1146#issuecomment-1573943898 From kcr at openjdk.org Fri Jun 2 15:47:10 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Jun 2023 15:47:10 GMT Subject: RFR: 8309001: Add Linux/riscv64 support to WebKit In-Reply-To: References: Message-ID: On Tue, 30 May 2023 17:39:57 GMT, Eric Long wrote: > RISC-V is a new free and open-source ISA that is being widely adopted in the recent years. Currently WebKit is ready for riscv64, and only minor changes is needed to support the platform. Can you trigger a GHA run? Since it wasn't enabled when you first pushed your branch, I don't know if you can trigger it manually or not. You might need to push a new commit (either an empty commit or by merging with the latest upstream master) to trigger a GHA run. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1146#issuecomment-1573948046 From duke at openjdk.org Fri Jun 2 15:56:23 2023 From: duke at openjdk.org (Eric Long) Date: Fri, 2 Jun 2023 15:56:23 GMT Subject: RFR: 8309001: Add Linux/riscv64 support to WebKit [v2] In-Reply-To: References: Message-ID: <7P006bObWwZn_RS8jOFt0YM1bEM91TPQljvJYDcyGPk=.ae16d69f-7925-45fe-9d82-e2b76322f6cb@github.com> > RISC-V is a new free and open-source ISA that is being widely adopted in the recent years. Currently WebKit is ready for riscv64, and only minor changes is needed to support the platform. Eric Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8309001: Add Linux/riscv64 support ------------- Changes: https://git.openjdk.org/jfx/pull/1146/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1146&range=01 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1146.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1146/head:pull/1146 PR: https://git.openjdk.org/jfx/pull/1146 From duke at openjdk.org Fri Jun 2 15:56:24 2023 From: duke at openjdk.org (Eric Long) Date: Fri, 2 Jun 2023 15:56:24 GMT Subject: RFR: 8309001: Add Linux/riscv64 support to WebKit In-Reply-To: References: Message-ID: On Tue, 30 May 2023 17:39:57 GMT, Eric Long wrote: > RISC-V is a new free and open-source ISA that is being widely adopted in the recent years. Currently WebKit is ready for riscv64, and only minor changes is needed to support the platform. Sorry I messed up a bit and force pushed, but the workflow should be triggered. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1146#issuecomment-1573957810 From kcr at openjdk.org Fri Jun 2 16:23:13 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Jun 2023 16:23:13 GMT Subject: RFR: 8309001: Add Linux/riscv64 support to WebKit In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 15:53:00 GMT, Eric Long wrote: > Sorry I messed up a bit and force pushed, but the workflow should be triggered. The GHA run was triggered, thanks. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1146#issuecomment-1574002389 From kcr at openjdk.org Fri Jun 2 16:26:14 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Jun 2023 16:26:14 GMT Subject: RFR: 8309001: Add Linux/riscv64 support to WebKit [v2] In-Reply-To: <7P006bObWwZn_RS8jOFt0YM1bEM91TPQljvJYDcyGPk=.ae16d69f-7925-45fe-9d82-e2b76322f6cb@github.com> References: <7P006bObWwZn_RS8jOFt0YM1bEM91TPQljvJYDcyGPk=.ae16d69f-7925-45fe-9d82-e2b76322f6cb@github.com> Message-ID: On Fri, 2 Jun 2023 15:56:23 GMT, Eric Long wrote: >> RISC-V is a new free and open-source ISA that is being widely adopted in the recent years. Currently WebKit is ready for riscv64, and only minor changes is needed to support the platform. > > Eric Long 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 one additional commit since the last revision: > > 8309001: Add Linux/riscv64 support The changes look OK to me. @jaybhaskar Can you also review this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1146#issuecomment-1574005488 From kcr at openjdk.org Fri Jun 2 16:37:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Jun 2023 16:37:21 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v14] In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 04:17:23 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: > > - Merge branch 'master' into allow-reproducible-builds > - Revert format of timestamp in version OPT field > - Merge branch 'master' into allow-reproducible-builds > > Include two commits that fix WebKit build failures on Windows and macOS: > > 8282359: Intermittent WebKit build failure on Windows: > C1090: PDB API call failed, error code 23 > 8286089: Intermittent WebKit build failure on macOS in JavaScriptCore > - Merge branch 'master' into allow-reproducible-builds > - Support JDK 17 GA or later for building JavaFX > - Merge branch 'master' into allow-reproducible-builds > - Add '--date' argument for deterministic JMOD files > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - Comment out 'jmod --date' until building on JDK 19 > > Support for the 'jmod --date' option was added to JDK 19 starting > with the 19+2 early-access build, and it was backported to JDK 17 > starting with release 17.0.3. It is not available in JDK 18. > - ... and 13 more: https://git.openjdk.org/jfx/compare/559ad113...842470ae Now that the compiler updates are in, I'll resume reviewing and testing this. I'd like to get it in soon. @jgneff Can you merge in the latest master? This will pick up the recent compiler updates along with any other recent changes. I'll do that anyway when testing, but that way we'll get a GHA run on Mac and Linux with the latest compilers. ------------- PR Comment: https://git.openjdk.org/jfx/pull/446#issuecomment-1574017793 From kcr at openjdk.org Fri Jun 2 18:36:12 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Jun 2023 18:36:12 GMT Subject: RFR: 8306648: Update the JavaDocs to show the NEW section and DEPRECATED versions In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 13:30:38 GMT, Nir Lisker wrote: > 1. The `-since` option does not play well with the javafx one: if documentation was added on a `private` property field with the `@since` tag, it will not be included in the NEW and DEPRECATED lists. I presume that the `-since` release version comparison detects only public APIs and does not know that javafx generates public API from private members. Confirmed. I can file a bug against the javadoc tool. This looks like one more place where they need to handle JavaFX properties. > 2. I started from version 9, but there are also versions "8" and "8u20" in the deprecation list, and "JavaFX 8u40" and "JavaFX 8.0" in `@since` tags. For comparison, the JDK starts from 12 (https://docs.oracle.com/en/java/javase/20/docs/api/new-list.html). I'm not sure what versions we want to include. Changing this is simply done by adding the strings that appear in the tags to the `-since` option list. I might recommend starting with 11, but I don't mind starting with 9 if others feel that's best. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1109#issuecomment-1574152608 From prr at openjdk.org Fri Jun 2 18:40:17 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 2 Jun 2023 18:40:17 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v4] In-Reply-To: <-hBaKlQFbHotzTm2Rx62yWyl_h9bZS5wIua5ITP-9Bg=.ce7cf302-974e-4c8f-8408-1a9b7a031609@github.com> References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <2c5EycXlOR17gt5cf_1xOE_Ncm0BBiRNugiCKFuVTe4=.e9e13776-d795-4745-9caa-8e33452f7ac1@github.com> <9H_C_l0oasD3Gw7ahd3mqSkCSp1kl3wUTsAr3Wg2iK8=.459eeb19-3569-431b-981a-0fb827e72f83@github.com> <-hBaKlQFbHotzTm2Rx62yWyl_h9bZS5wIua5ITP-9Bg=.ce7cf302-974e-4c8f-8408-1a9b7a031609@github.com> Message-ID: On Fri, 2 Jun 2023 07:19:01 GMT, Karthik P K wrote: >> The main issue is that insertion index was not computed in the PrismTextLayout, supposedly to allow for delaying the computation until it's needed (if needed at all). A good intention, but the execution had two issues: >> 1. HitInfo obtained in TextFlow had its 'text' field set to null (TextFlow:204), disabling any possibility of computing the index correctly >> 2. The code that computed the index had an issue in that if an exception happened, it left the object in an inconsistent state, leading to other problems down the road, and more exceptions (incl. AIOB) >> >> What we did here is to compute the insertion index correctly at the source. >> I've also checked that in the case of an empty line the insertion index is correct in both cases (at the last line and in the middle of a document). > >> Assuming line 473 is the one still there today, it looks to me as if that would be reached if you had the caret on an empty line that isn't the last line. > > In this case also code hits the condition in 451 as the text run is not null. > >>it seems to me that this new code has been pretty much copied from the supposedly buggy code there .. > I'm not sure that code is actually buggy (comments over in that bug), rather that the instance was constructed > with bad data. > > Like Andy said, since text was null in `HitInfo::getInsertionIndex()` method in the case of TextFlow, correct insertion index was not calculated. I had to use pretty much same code in PrismTextLayout as I had to consider all the cases especially the U+FE0F Variation Selector-16 characters. I did note that TextFlow passed null which really looked like a WIP to me but its a separate issue. The exception in 8302511 which is the entire subject of that bug isn't possible if text == null. My point is that if you pass an incorrect charIndex to BreakIterator.following() you'll get the same exception in your copy of that code. So how are you making sure you never do that ? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1214692324 From kcr at openjdk.org Fri Jun 2 18:45:13 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Jun 2023 18:45:13 GMT Subject: RFR: 8306648: Update the JavaDocs to show the NEW section and DEPRECATED versions [v2] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 11:39:24 GMT, Nir Lisker wrote: >> Adds the javadoc commands to generate the NEW page and to be able to select versions in the DEPRECATED page. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Auto-detect latest version @johanvos @andy-goryachev-oracle Do either of you have an opinion on this PR? I'm especially interested in knowing whether we should include 9 and 10 in the (growing) list of versions shown in the NEW API section (they'll show up in the DEPRECATED section regardless). See the attached screenshot. ![javadoc-since](https://github.com/openjdk/jfx/assets/34689748/59e7ac98-8251-4728-8fdc-8ce66801b325) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1109#issuecomment-1574162147 From angorya at openjdk.org Fri Jun 2 18:53:18 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Jun 2023 18:53:18 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v4] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <2c5EycXlOR17gt5cf_1xOE_Ncm0BBiRNugiCKFuVTe4=.e9e13776-d795-4745-9caa-8e33452f7ac1@github.com> <9H_C_l0oasD3Gw7ahd3mqSkCSp1kl3wUTsAr3Wg2iK8=.459eeb19-3569-431b-981a-0fb827e72f83@github.com> <-hBaKlQFbHotzTm2Rx62yWyl_h9bZS5wIua5ITP-9Bg=.ce7cf302-974e-4c8f-8408-1a9b7a031609@github.com> Message-ID: On Fri, 2 Jun 2023 18:37:19 GMT, Phil Race wrote: >>> Assuming line 473 is the one still there today, it looks to me as if that would be reached if you had the caret on an empty line that isn't the last line. >> >> In this case also code hits the condition in 451 as the text run is not null. >> >>>it seems to me that this new code has been pretty much copied from the supposedly buggy code there .. >> I'm not sure that code is actually buggy (comments over in that bug), rather that the instance was constructed >> with bad data. >> >> Like Andy said, since text was null in `HitInfo::getInsertionIndex()` method in the case of TextFlow, correct insertion index was not calculated. I had to use pretty much same code in PrismTextLayout as I had to consider all the cases especially the U+FE0F Variation Selector-16 characters. > > I did note that TextFlow passed null which really looked like a WIP to me but its a separate issue. > The exception in 8302511 which is the entire subject of that bug isn't possible if text == null. > My point is that if you pass an incorrect charIndex to BreakIterator.following() you'll get the same exception > in your copy of that code. So how are you making sure you never do that ? The exception in 8302511 was likely caused by a prior exception due to null text, which corrupted insertionIndex value in HitInfo. The goal of this change is to always compute insertionIndex (an I believe we do it correctly this time). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1214702879 From prr at openjdk.org Fri Jun 2 19:21:17 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 2 Jun 2023 19:21:17 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v4] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <2c5EycXlOR17gt5cf_1xOE_Ncm0BBiRNugiCKFuVTe4=.e9e13776-d795-4745-9caa-8e33452f7ac1@github.com> <9H_C_l0oasD3Gw7ahd3mqSkCSp1kl3wUTsAr3Wg2iK8=.459eeb19-3569-431b-981a-0fb827e72f83@github.com> <-hBaKlQFbHotzTm2Rx62yWyl_h9bZS5wIua5ITP-9Bg=.ce7cf302-974e-4c8f-8408-1a9b7a031609@github.com> Message-ID: <7W6re4KEAJK24FJnWTXK2HqbxLUvm40RQAkHztA1B38=.7887e6b5-a67c-4153-b713-eb5148516799@github.com> On Fri, 2 Jun 2023 18:50:07 GMT, Andy Goryachev wrote: >> I did note that TextFlow passed null which really looked like a WIP to me but its a separate issue. >> The exception in 8302511 which is the entire subject of that bug isn't possible if text == null. >> My point is that if you pass an incorrect charIndex to BreakIterator.following() you'll get the same exception >> in your copy of that code. So how are you making sure you never do that ? > > The exception in 8302511 was likely caused by a prior exception due to null text, which corrupted insertionIndex value in HitInfo. > > The goal of this change is to always compute insertionIndex (an I believe we do it correctly this time). No, it wasn't due to null text. That is provably impossible. The exception from JDK-8302511 is as follows (copied from the bug report). Exception in thread "JavaFX Application Thread" java.lang.IllegalArgumentException: offset out of bounds at java.base/sun.text.RuleBasedBreakIterator.checkOffset(RuleBasedBreakIterator.java:730) at java.base/sun.text.RuleBasedBreakIterator.following(RuleBasedBreakIterator.java:744) at javafx.graphics/javafx.scene.text.HitInfo.getInsertionIndex(HitInfo.java:84) at javafx.graphics/javafx.scene.text.HitInfo.toString(HitInfo.java:100) Look at the code in HitInfo.java referenced in JDK-8302511, the code at line 84 can only be reached if text != null .. if (text != null) { // Skip complex character clusters / ligatures. int next; synchronized(charIterator) { charIterator.setText(text); next = charIterator.following(insertionIndex); // this is line 84 } ... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1214735858 From kevin.rushforth at oracle.com Fri Jun 2 19:25:16 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 2 Jun 2023 12:25:16 -0700 Subject: JavaFX 20.0.2 will be closed for fixes on June 12th Message-ID: <12fc3bc3-6afb-4d14-e442-fd6acc424672@oracle.com> All, If you have fixes that you need to get into jfx20u for JavaFX 20.0.2, please do so by Monday, June 12th. Note that approval from one of the project leads is needed as outlined in this message [1]. Thanks. -- Kevin [1] https://mail.openjdk.org/pipermail/openjfx-dev/2023-March/039371.html From angorya at openjdk.org Fri Jun 2 19:44:17 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Jun 2023 19:44:17 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v4] In-Reply-To: <7W6re4KEAJK24FJnWTXK2HqbxLUvm40RQAkHztA1B38=.7887e6b5-a67c-4153-b713-eb5148516799@github.com> References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <2c5EycXlOR17gt5cf_1xOE_Ncm0BBiRNugiCKFuVTe4=.e9e13776-d795-4745-9caa-8e33452f7ac1@github.com> <9H_C_l0oasD3Gw7ahd3mqSkCSp1kl3wUTsAr3Wg2iK8=.459eeb19-3569-431b-981a-0fb827e72f83@github.com> <-hBaKlQFbHotzTm2Rx62yWyl_h9bZS5wIua5ITP-9Bg=.ce7cf302-974e-4c8f-8408-1a9b7a031609@github.com> <7W6re4KEAJK24FJnWTXK2HqbxLUvm40RQAkHztA1B38=.7887e6b5-a67c-4153-b713-eb5148516799@github.com> Message-ID: On Fri, 2 Jun 2023 19:18:13 GMT, Phil Race wrote: >> The exception in 8302511 was likely caused by a prior exception due to null text, which corrupted insertionIndex value in HitInfo. >> >> The goal of this change is to always compute insertionIndex (an I believe we do it correctly this time). > > No, it wasn't due to null text. That is provably impossible. > > The exception from JDK-8302511 is as follows (copied from the bug report). > > Exception in thread "JavaFX Application Thread" java.lang.IllegalArgumentException: offset out of bounds > at java.base/sun.text.RuleBasedBreakIterator.checkOffset(RuleBasedBreakIterator.java:730) > at java.base/sun.text.RuleBasedBreakIterator.following(RuleBasedBreakIterator.java:744) > at javafx.graphics/javafx.scene.text.HitInfo.getInsertionIndex(HitInfo.java:84) > at javafx.graphics/javafx.scene.text.HitInfo.toString(HitInfo.java:100) > Look at the code in HitInfo.java referenced in JDK-8302511, the code at line 84 can only be reached if text != null > .. > if (text != null) { > // Skip complex character clusters / ligatures. > int next; > synchronized(charIterator) { > charIterator.setText(text); > next = charIterator.following(insertionIndex); // this is line 84 > } > > ... you are right, it cannot be explained by a null text. so if i understand you correctly, the question is about validity of `insertionIndex += 1` on lines 463 and 469. 463: should it be set to text.length() instead? 469: since text==null, could `insertionIndex = charIndex + 1` be correct? And also, is it possible at all that text == null within PrismTextLayout? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1214758417 From prr at openjdk.org Fri Jun 2 21:00:19 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 2 Jun 2023 21:00:19 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v4] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <2c5EycXlOR17gt5cf_1xOE_Ncm0BBiRNugiCKFuVTe4=.e9e13776-d795-4745-9caa-8e33452f7ac1@github.com> <9H_C_l0oasD3Gw7ahd3mqSkCSp1kl3wUTsAr3Wg2iK8=.459eeb19-3569-431b-981a-0fb827e72f83@github.com> <-hBaKlQFbHotzTm2Rx62yWyl_h9bZS5wIua5ITP-9Bg=.ce7cf302-974e-4c8f-8408-1a9b7a031609@github.com> <7W6re4KEAJK24FJnWTXK2HqbxLUvm40RQAkHztA1B38=.7887e6b5-a67c-4153-b713-eb5148516799@github.com> Message-ID: On Fri, 2 Jun 2023 19:41:04 GMT, Andy Goryachev wrote: >> No, it wasn't due to null text. That is provably impossible. >> >> The exception from JDK-8302511 is as follows (copied from the bug report). >> >> Exception in thread "JavaFX Application Thread" java.lang.IllegalArgumentException: offset out of bounds >> at java.base/sun.text.RuleBasedBreakIterator.checkOffset(RuleBasedBreakIterator.java:730) >> at java.base/sun.text.RuleBasedBreakIterator.following(RuleBasedBreakIterator.java:744) >> at javafx.graphics/javafx.scene.text.HitInfo.getInsertionIndex(HitInfo.java:84) >> at javafx.graphics/javafx.scene.text.HitInfo.toString(HitInfo.java:100) >> Look at the code in HitInfo.java referenced in JDK-8302511, the code at line 84 can only be reached if text != null >> .. >> if (text != null) { >> // Skip complex character clusters / ligatures. >> int next; >> synchronized(charIterator) { >> charIterator.setText(text); >> next = charIterator.following(insertionIndex); // this is line 84 >> } >> >> ... > > you are right, it cannot be explained by a null text. > > so if i understand you correctly, the question is about validity of `insertionIndex += 1` on lines 463 and 469. > > 463: should it be set to text.length() instead? > > 469: since text==null, could `insertionIndex = charIndex + 1` be correct? > > And also, is it possible at all that text == null within PrismTextLayout? No, because that's after the call to BreakIterator.following(int) It is mainly about the assignment on line 456 > insertionIndex = charIndex; since that is what gets passed to BreakIterator.following(int) and charIndex was calculated by charIndex = run.getStart() + run.getOffsetAtX(x, trailing); so it goes back to that calculation. Perhaps a simple validation that charIndex is not out of bounds is all that is needed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1214832843 From tsayao at openjdk.org Sat Jun 3 21:21:54 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 3 Jun 2023 21:21:54 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v15] In-Reply-To: References: Message-ID: <5zpsfsEg6wI5rOldwKNMOscJ8vBazhrTNBLgo3nL1q4=.0e13691f-561b-4e9f-a654-c59cef7167d7@github.com> > I replicated the fix on #1054 on Linux. > > Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) 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 58 additional commits since the last revision: - Merge branch 'master' into change_scene_fix - Can't get size before process_configure - Fix MouseEventFirerTest.java - Merge branch 'master' into change_scene_fix - Antecipate request focus - Merge branch 'master' into change_scene_fix - Fix ComboBoxTest - Add manual test - Merge branch 'master' into change_scene_fix - Merge branch 'openjdk:master' into master - ... and 48 more: https://git.openjdk.org/jfx/compare/dbbe9819...849d5dc3 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1110/files - new: https://git.openjdk.org/jfx/pull/1110/files/b0857a07..849d5dc3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=14 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=13-14 Stats: 38098 lines in 816 files changed: 10693 ins; 3279 del; 24126 mod Patch: https://git.openjdk.org/jfx/pull/1110.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1110/head:pull/1110 PR: https://git.openjdk.org/jfx/pull/1110 From tsayao at openjdk.org Sat Jun 3 22:30:21 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 3 Jun 2023 22:30:21 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v15] In-Reply-To: <5zpsfsEg6wI5rOldwKNMOscJ8vBazhrTNBLgo3nL1q4=.0e13691f-561b-4e9f-a654-c59cef7167d7@github.com> References: <5zpsfsEg6wI5rOldwKNMOscJ8vBazhrTNBLgo3nL1q4=.0e13691f-561b-4e9f-a654-c59cef7167d7@github.com> Message-ID: On Sat, 3 Jun 2023 21:21:54 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > 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 58 additional commits since the last revision: > > - Merge branch 'master' into change_scene_fix > - Can't get size before process_configure > - Fix MouseEventFirerTest.java > - Merge branch 'master' into change_scene_fix > - Antecipate request focus > - Merge branch 'master' into change_scene_fix > - Fix ComboBoxTest > - Add manual test > - Merge branch 'master' into change_scene_fix > - Merge branch 'openjdk:master' into master > - ... and 48 more: https://git.openjdk.org/jfx/compare/0144a73a...849d5dc3 For some reason `Platform.startup` is hanging and any test that uses it gets stuck. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1575232210 From jbhaskar at openjdk.org Sun Jun 4 01:47:12 2023 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Sun, 4 Jun 2023 01:47:12 GMT Subject: RFR: 8309001: Add Linux/riscv64 support to WebKit [v2] In-Reply-To: <7P006bObWwZn_RS8jOFt0YM1bEM91TPQljvJYDcyGPk=.ae16d69f-7925-45fe-9d82-e2b76322f6cb@github.com> References: <7P006bObWwZn_RS8jOFt0YM1bEM91TPQljvJYDcyGPk=.ae16d69f-7925-45fe-9d82-e2b76322f6cb@github.com> Message-ID: On Fri, 2 Jun 2023 15:56:23 GMT, Eric Long wrote: >> RISC-V is a new free and open-source ISA that is being widely adopted in the recent years. Currently WebKit is ready for riscv64, and only minor changes is needed to support the platform. > > Eric Long 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 one additional commit since the last revision: > > 8309001: Add Linux/riscv64 support Webkit has web assembly implementation, in the case of enabling risc64, we need to check any building issue with WebKit, by enabling wasm. The build error usually happens in case of debug build. ------------- PR Review: https://git.openjdk.org/jfx/pull/1146#pullrequestreview-1460673388 From duke at openjdk.org Sun Jun 4 12:15:14 2023 From: duke at openjdk.org (Eric Long) Date: Sun, 4 Jun 2023 12:15:14 GMT Subject: RFR: 8309001: Add Linux/riscv64 support to WebKit [v2] In-Reply-To: <7P006bObWwZn_RS8jOFt0YM1bEM91TPQljvJYDcyGPk=.ae16d69f-7925-45fe-9d82-e2b76322f6cb@github.com> References: <7P006bObWwZn_RS8jOFt0YM1bEM91TPQljvJYDcyGPk=.ae16d69f-7925-45fe-9d82-e2b76322f6cb@github.com> Message-ID: <6LsZwDOTx3mj-mtitRYTn8tQoOKS1Lqnh_eBTTPcEuk=.d4e6f86c-cf79-43fe-a094-6000bd1a574f@github.com> On Fri, 2 Jun 2023 15:56:23 GMT, Eric Long wrote: >> RISC-V is a new free and open-source ISA that is being widely adopted in the recent years. Currently WebKit is ready for riscv64, and only minor changes is needed to support the platform. > > Eric Long 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 one additional commit since the last revision: > > 8309001: Add Linux/riscv64 support I just noticed Oracle added 'to Webkit' to my bug report title. This patch only allows OpenJFX to build on riscv64 and WebKit already did that. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1146#issuecomment-1575545999 From tsayao at openjdk.org Sun Jun 4 13:41:12 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 4 Jun 2023 13:41:12 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v16] In-Reply-To: References: Message-ID: > I replicated the fix on #1054 on Linux. > > Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Forgot definition ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1110/files - new: https://git.openjdk.org/jfx/pull/1110/files/849d5dc3..4f98f1eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=15 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=14-15 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1110.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1110/head:pull/1110 PR: https://git.openjdk.org/jfx/pull/1110 From tsayao at openjdk.org Sun Jun 4 17:40:44 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 4 Jun 2023 17:40:44 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v17] In-Reply-To: References: Message-ID: > I replicated the fix on #1054 on Linux. > > Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Update view size when size is oriented by WINDOW size ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1110/files - new: https://git.openjdk.org/jfx/pull/1110/files/4f98f1eb..9130320f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=16 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=15-16 Stats: 37 lines in 2 files changed: 28 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1110.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1110/head:pull/1110 PR: https://git.openjdk.org/jfx/pull/1110 From tsayao at openjdk.org Sun Jun 4 17:42:18 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 4 Jun 2023 17:42:18 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v16] In-Reply-To: References: Message-ID: On Sun, 4 Jun 2023 13:41:12 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Forgot definition The problem happens only when `Scene` is created without size, so it expands to `Window` size. If `Scene` has the size specified, the bug does not happen. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1575651880 From tsayao at openjdk.org Sun Jun 4 18:48:29 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 4 Jun 2023 18:48:29 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v18] In-Reply-To: References: Message-ID: <90Qbdi_mFQbCH7sn5q1Jf_wJbWa9HK_QWDWyRoRAeGk=.350ee310-1ad4-4cd8-bb0f-67e5cf0084a1@github.com> > I replicated the fix on #1054 on Linux. > > Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Unchanged line ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1110/files - new: https://git.openjdk.org/jfx/pull/1110/files/9130320f..e569a9f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=17 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=16-17 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1110.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1110/head:pull/1110 PR: https://git.openjdk.org/jfx/pull/1110 From tsayao at openjdk.org Sun Jun 4 18:56:16 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 4 Jun 2023 18:56:16 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v18] In-Reply-To: <90Qbdi_mFQbCH7sn5q1Jf_wJbWa9HK_QWDWyRoRAeGk=.350ee310-1ad4-4cd8-bb0f-67e5cf0084a1@github.com> References: <90Qbdi_mFQbCH7sn5q1Jf_wJbWa9HK_QWDWyRoRAeGk=.350ee310-1ad4-4cd8-bb0f-67e5cf0084a1@github.com> Message-ID: On Sun, 4 Jun 2023 18:48:29 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Unchanged line Maybe it's possible to do a Java fix where the new Scene without size inherits the old Scene size? This way I think it possible to remove platform specific code such as the one I did and `_updateViewSize`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1575673291 From tsayao at openjdk.org Sun Jun 4 21:09:12 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 4 Jun 2023 21:09:12 GMT Subject: RFR: 8303038: Glass gtk3 sends scroll events with delta(x, y) = 0 [v9] In-Reply-To: References: <9H9NFSADpb1CL6zwN-Q8kdJUnId5CcSUo1KlBnTnP0Q=.41ca5b87-ae78-4ef9-89ac-c867a2517533@github.com> Message-ID: On Sun, 28 May 2023 20:53:27 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to get the scroll deltas from GDK_SCROLL_SMOOTH. If we ignore this scroll event type, deltas are sent to java with the value equal to zero. >> >> Here's whats happening: >> >> We include all event masks, so when using gtk3 (>= 3.4.0) it includes `GDK_SMOOTH_SCROLL_MASK` meaning we receive duplicated events, one with `direction = GDK_SMOOTH_SCROLL_MASK` and other with "legacy" direction (UP/DOWN). >> >> When receiving the event corresponding to `GDK_SMOOTH_SCROLL_MASK` we ignored it causing it to send deltas (x,y) = 0. >> >> The fix now checks if `GDK_SMOOTH_SCROLL_MASK` is supported and uses it, also adding smooth scroll functionality. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Listen only to smooth deltas I did some testing. Removing `GDK_SCROLL_MASK ` does not work, it's sent anyways. The current solution ignores the discrete scroll and uses the smooth deltas only. This is the way I was targeting (to check if smooth or discrete): https://docs.gtk.org/gdk3/method.Event.get_scroll_direction.html But in reality both smooth and non-smooth events are sent for a regular mouse device and a few non-smooth for touchpad. Using GTK event signals, only smooth events are received: #include // Callback function for scroll events gboolean on_scroll_event(GtkWidget *widget, GdkEventScroll *event, gpointer user_data) { if (event->direction == GDK_SCROLL_UP) { g_print("Scroll Up\n"); } else if (event->direction == GDK_SCROLL_DOWN) { g_print("Scroll Down\n"); } if (event->delta_y > 0) { g_print("Smooth Scroll Up\n"); } else if (event->delta_y < 0) { g_print("Smooth Scroll Down\n"); } // Return FALSE to propagate the event further or TRUE to stop it return FALSE; } int main(int argc, char *argv[]) { gtk_init(&argc, &argv); GtkWidget *window = gtk_window_new(GTK_WINDOW_TOPLEVEL); gtk_window_set_default_size(GTK_WINDOW(window), 200, 200); GtkWidget *scrolled_window = gtk_scrolled_window_new(NULL, NULL); gtk_container_set_border_width(GTK_CONTAINER(scrolled_window), 10); gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(scrolled_window), GTK_POLICY_AUTOMATIC, GTK_POLICY_AUTOMATIC); GtkWidget *viewport = gtk_viewport_new(NULL, NULL); gtk_container_add(GTK_CONTAINER(scrolled_window), viewport); GtkWidget *label = gtk_label_new("Scrollable Content"); gtk_container_add(GTK_CONTAINER(viewport), label); g_signal_connect(G_OBJECT(scrolled_window), "scroll-event", G_CALLBACK(on_scroll_event), NULL); gtk_container_add(GTK_CONTAINER(window), scrolled_window); gtk_widget_show_all(window); gtk_main(); return 0; } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1044#issuecomment-1575718476 From aghaisas at openjdk.org Mon Jun 5 09:29:22 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 5 Jun 2023 09:29:22 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v7] In-Reply-To: <_cRT1w2QchXm5_KUdMpOjONs6weVvJ9A53cLzVAOrYU=.2de6eca4-d1ae-43c0-89c3-af7db1fddbf9@github.com> References: <_cRT1w2QchXm5_KUdMpOjONs6weVvJ9A53cLzVAOrYU=.2de6eca4-d1ae-43c0-89c3-af7db1fddbf9@github.com> Message-ID: On Mon, 15 May 2023 16:12:10 GMT, Andy Goryachev wrote: >> Fixed a memory leak in TreeTableView by reverting to register**Listener (which is ok in this particular situation) - the leak is specific to TreeTableRowSkin. >> >> Added a unit test. > > Andy Goryachev 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 17 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8307538.refresh > - review comments > - John is right > - review comments > - one more test case > - back to register listener > - weak lambdas are getting collected > - removed monkey tester changes > - Merge remote-tracking branch 'origin/master' into 8307538.refresh > - whitespace > - ... and 7 more: https://git.openjdk.org/jfx/compare/c0c029a0...f68de127 The fix looks good to me! ------------- Marked as reviewed by aghaisas (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1129#pullrequestreview-1462118493 From kpk at openjdk.org Mon Jun 5 11:16:52 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 5 Jun 2023 11:16:52 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v9] In-Reply-To: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: > Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. > > Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. > The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. > > Added system test to validate the fix. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Add out of bound check for insertion index ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1091/files - new: https://git.openjdk.org/jfx/pull/1091/files/4d6dd9f3..ea940bf4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1091&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1091&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1091.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1091/head:pull/1091 PR: https://git.openjdk.org/jfx/pull/1091 From kpk at openjdk.org Mon Jun 5 11:42:18 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 5 Jun 2023 11:42:18 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v4] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <2c5EycXlOR17gt5cf_1xOE_Ncm0BBiRNugiCKFuVTe4=.e9e13776-d795-4745-9caa-8e33452f7ac1@github.com> <9H_C_l0oasD3Gw7ahd3mqSkCSp1kl3wUTsAr3Wg2iK8=.459eeb19-3569-431b-981a-0fb827e72f83@github.com> <-hBaKlQFbHotzTm2Rx62yWyl_h9bZS5wIua5ITP-9Bg=.ce7cf302-974e-4c8f-8408-1a9b7a031609@github.com> <7W6re4KEAJK24FJnWTXK2HqbxLUvm40RQAkHztA1B38=.7887e6b5-a67c-4153-b713-eb5148516799@github.com> Message-ID: On Fri, 2 Jun 2023 20:57:06 GMT, Phil Race wrote: >> you are right, it cannot be explained by a null text. >> >> so if i understand you correctly, the question is about validity of `insertionIndex += 1` on lines 463 and 469. >> >> 463: should it be set to text.length() instead? >> >> 469: since text==null, could `insertionIndex = charIndex + 1` be correct? >> >> And also, is it possible at all that text == null within PrismTextLayout? > > No, because that's after the call to BreakIterator.following(int) > It is mainly about the assignment on line 456 >> insertionIndex = charIndex; > > since that is what gets passed to BreakIterator.following(int) > > and charIndex was calculated by > charIndex = run.getStart() + run.getOffsetAtX(x, trailing); > so it goes back to that calculation. > Perhaps a simple validation that charIndex is not out of bounds is all that is needed. Added check to make sure that insertion index passed to BreakIterator.following(int) is not out of bound. Added this check after line 456 `insertionIndex = charIndex;`, otherwise insertionIndex remains as -1 and `Hitinfo::getInsertionIndex` will calculate wrong insertionIndex. Please check the change. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1217947206 From mhanl at openjdk.org Mon Jun 5 12:40:16 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 5 Jun 2023 12:40:16 GMT Subject: RFR: 8293836: Rendering performance degradation at bottom of TableView with many rows [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 13:55:05 GMT, Kevin Rushforth wrote: >> @johanvos I still think this should be evaluated. > > Perhaps you could file a follow-up JBS issue? Filed: https://bugs.openjdk.org/browse/JDK-8309470 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1098#discussion_r1218014420 From arapte at openjdk.org Mon Jun 5 13:35:20 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 5 Jun 2023 13:35:20 GMT Subject: RFR: 8301312: Create implementation of NSAccessibilityButton protocol [v7] In-Reply-To: <60dQv4GV4rT-lmSQspiz55C4HOVryoD6abb-WqYJ4tc=.808234a3-12b6-428e-b3d0-c1cee8d13530@github.com> References: <60dQv4GV4rT-lmSQspiz55C4HOVryoD6abb-WqYJ4tc=.808234a3-12b6-428e-b3d0-c1cee8d13530@github.com> Message-ID: On Wed, 31 May 2023 20:48:05 GMT, Alexander Zuev wrote: >> Add the common base component for all the new implementing native classes Change native peer creation to use the new base component The new code will instantiate new protocol implementation for the given role if it exists or an old one if it does not exist >> Added BUTTON role implementing class > > Alexander Zuev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into JDK-8301312 > - Changing performAction parameter to NSString > - Merge remote-tracking branch 'refs/remotes/origin/JDK-8301312' into JDK-8301312 > - Properly use NSObject instead of the GlassAccessible type. > - Fixed situation when performAction throws an exception on Java side - now we are properly > returning FALSE notifying system that action has not been performed successfully. > - Fixes based on review. > Modified parent retrieval to cache the parent inside the component peer because retrieving parent every time > can be costly. > - 8301312: Create implementation of NSAccessibilityButton protocol > > Add the common base component for all the new implementing native classes > Change native peer creation to use the new base component > The new code will instantiate new protocol implementation for the given role > if it exists or an old one if it does not exist > Added BUTTON role implementing class > - Properly use NSObject instead of the GlassAccessible type. > - Fixed situation when performAction throws an exception on Java side - now we are properly > returning FALSE notifying system that action has not been performed successfully. > - Fixes based on review. > Modified parent retrieval to cache the parent inside the component peer because retrieving parent every time > can be costly. > - ... and 1 more: https://git.openjdk.org/jfx/compare/f8c8a8a1...871a2ad5 Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1084#pullrequestreview-1462554162 From angorya at openjdk.org Mon Jun 5 16:22:27 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Jun 2023 16:22:27 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v9] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: On Mon, 5 Jun 2023 11:16:52 GMT, Karthik P K wrote: >> Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. >> >> Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. >> The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. >> >> Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add out of bound check for insertion index The new code also exhibits a strange behavior in the RichTextArea (based ob TextFlow): I am unable to position the cursor at the end of ?????? emoji sequence with the mouse (unless I click on the next empty line). tests/system/src/test/java/test/robot/javafx/scene/TextFlowSurrogatePairInsertionIndexTest.java line 151: > 149: private void addMultipleEmojis() { > 150: Util.runAndWait(() -> { > 151: text = new Text("??????"); Both new code (the last commit) and the old code (previous commit) fail this test if the text string is the following sequence: ?????? \u261d\ud83c\udfff\u261d\ud83c\udfff\u261d\ud83c\udfff I've tried it with jdk19 and jdk20.0.1 (the latter contains a BreakInterator change [JDK-8291660](https://bugs.openjdk.org/browse/JDK-8291660) that alters its handling of grapheme clusters. Exception: java.lang.AssertionError: expected:<0> but was:<1> at org.junit.Assert.fail(Assert.java:89) at org.junit.Assert.failNotEquals(Assert.java:835) at org.junit.Assert.assertEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:633) at test.robot.javafx.scene.TextFlowSurrogatePairInsertionIndexTest.testTextFlowInsertionIndexUsingMultipleEmojis(TextFlowSurrogatePairInsertionIndexTest.java:216) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.junit.runner.JUnitCore.run(JUnitCore.java:137) at org.junit.runner.JUnitCore.run(JUnitCore.java:115) at org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42) at org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80) at org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:147) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:127) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:90) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:55) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:102) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:54) at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:114) at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:95) at org.junit.platform.launcher.core.DefaultLauncherSession$DelegatingLauncher.execute(DefaultLauncherSession.java:91) at org.junit.platform.launcher.core.SessionPerRequestLauncher.execute(SessionPerRequestLauncher.java:60) at org.eclipse.jdt.internal.junit5.runner.JUnit5TestReference.run(JUnit5TestReference.java:98) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:40) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:529) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:756) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:452) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:210) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1091#issuecomment-1577099109 PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1218267510 From kcr at openjdk.org Mon Jun 5 16:45:16 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 5 Jun 2023 16:45:16 GMT Subject: RFR: 8309001: Add Linux/riscv64 support to WebKit [v2] In-Reply-To: <7P006bObWwZn_RS8jOFt0YM1bEM91TPQljvJYDcyGPk=.ae16d69f-7925-45fe-9d82-e2b76322f6cb@github.com> References: <7P006bObWwZn_RS8jOFt0YM1bEM91TPQljvJYDcyGPk=.ae16d69f-7925-45fe-9d82-e2b76322f6cb@github.com> Message-ID: On Fri, 2 Jun 2023 15:56:23 GMT, Eric Long wrote: >> RISC-V is a new free and open-source ISA that is being widely adopted in the recent years. Currently WebKit is ready for riscv64, and only minor changes is needed to support the platform. > > Eric Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8309001: Add Linux/riscv64 support Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1146#pullrequestreview-1462963571 From kcr at openjdk.org Mon Jun 5 16:45:18 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 5 Jun 2023 16:45:18 GMT Subject: RFR: 8309001: Add Linux/riscv64 support to WebKit [v2] In-Reply-To: <6LsZwDOTx3mj-mtitRYTn8tQoOKS1Lqnh_eBTTPcEuk=.d4e6f86c-cf79-43fe-a094-6000bd1a574f@github.com> References: <7P006bObWwZn_RS8jOFt0YM1bEM91TPQljvJYDcyGPk=.ae16d69f-7925-45fe-9d82-e2b76322f6cb@github.com> <6LsZwDOTx3mj-mtitRYTn8tQoOKS1Lqnh_eBTTPcEuk=.d4e6f86c-cf79-43fe-a094-6000bd1a574f@github.com> Message-ID: <9CPExWxkIiGbJgfihDeF3nigvwvCGQ0WsC22L6JT_gA=.2fd4b2de-f554-4a81-b442-3dbd922ed612@github.com> On Sun, 4 Jun 2023 12:12:56 GMT, Eric Long wrote: > I just noticed Oracle added 'to Webkit' to my bug report title. This patch only allows OpenJFX to build on riscv64 and WebKit already did that. @hack3ric I just now changed the bug title to: Allow building JavaFX on Linux/riscv64 Please change the PR title to match the updated bug title. FWIW, as long as it doesn't break any supported platforms, I think it is OK to take this fix. Since it isn't WebKit-specific, perhaps @arapte can be the second reviewer? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1146#issuecomment-1577129725 From kizune at openjdk.org Mon Jun 5 17:10:20 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 5 Jun 2023 17:10:20 GMT Subject: Integrated: 8301312: Create implementation of NSAccessibilityButton protocol In-Reply-To: References: Message-ID: On Thu, 6 Apr 2023 20:43:13 GMT, Alexander Zuev wrote: > Add the common base component for all the new implementing native classes Change native peer creation to use the new base component The new code will instantiate new protocol implementation for the given role if it exists or an old one if it does not exist > Added BUTTON role implementing class This pull request has now been integrated. Changeset: 05548ace Author: Alexander Zuev Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/05548ace27f099a5ce152e3fb9efb4d22da683c8 Stats: 421 lines in 7 files changed: 372 ins; 41 del; 8 mod 8301312: Create implementation of NSAccessibilityButton protocol Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1084 From angorya at openjdk.org Mon Jun 5 17:15:21 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Jun 2023 17:15:21 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v9] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: On Mon, 5 Jun 2023 11:16:52 GMT, Karthik P K wrote: >> Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. >> >> Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. >> The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. >> >> Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add out of bound check for insertion index FYI, I've added "Enter Text" button to Text/TextFlow pages in the Monkey Tester https://github.com/andy-goryachev-oracle/MonkeyTest it might be easier to test various emojis and text strings with it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1091#issuecomment-1577172797 From kcr at openjdk.org Mon Jun 5 20:21:04 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 5 Jun 2023 20:21:04 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v7] In-Reply-To: <_cRT1w2QchXm5_KUdMpOjONs6weVvJ9A53cLzVAOrYU=.2de6eca4-d1ae-43c0-89c3-af7db1fddbf9@github.com> References: <_cRT1w2QchXm5_KUdMpOjONs6weVvJ9A53cLzVAOrYU=.2de6eca4-d1ae-43c0-89c3-af7db1fddbf9@github.com> Message-ID: On Mon, 15 May 2023 16:12:10 GMT, Andy Goryachev wrote: >> Fixed a memory leak in TreeTableView by reverting to register**Listener (which is ok in this particular situation) - the leak is specific to TreeTableRowSkin. >> >> Added a unit test. > > Andy Goryachev 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 17 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8307538.refresh > - review comments > - John is right > - review comments > - one more test case > - back to register listener > - weak lambdas are getting collected > - removed monkey tester changes > - Merge remote-tracking branch 'origin/master' into 8307538.refresh > - whitespace > - ... and 7 more: https://git.openjdk.org/jfx/compare/c0438b85...f68de127 Looks good. @hjohn Did you want to re-review (there was only one cleanup change since you approved)? ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1129#pullrequestreview-1463331440 From kcr at openjdk.org Mon Jun 5 21:13:07 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 5 Jun 2023 21:13:07 GMT Subject: RFR: 8304290: Some JNI calls made without checking exceptions in media [v2] In-Reply-To: References: Message-ID: On Wed, 31 May 2023 22:36:54 GMT, Alexander Matveev wrote: >> - Added missing exception checks for JNI calls. >> - Improved JNI error checking by checking for both exception and return value. >> - Minor code clean up. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8304290: Some JNI calls made without checking exceptions in media [v2] I identified two potential issues (see below). The rest looks good. modules/javafx.media/src/main/native/jfxmedia/jni/JavaPlayerEventDispatcher.cpp line 199: > 197: } > 198: > 199: pEnv->DeleteLocalRef(jmessage); This needs to be moved inside the previous `if` block. modules/javafx.media/src/main/native/jfxmedia/jni/JniUtils.cpp line 59: > 57: } > 58: // This shouldn't happen... > 59: return; Don't you still need this `return`? ------------- PR Review: https://git.openjdk.org/jfx/pull/1094#pullrequestreview-1463420165 PR Review Comment: https://git.openjdk.org/jfx/pull/1094#discussion_r1218582474 PR Review Comment: https://git.openjdk.org/jfx/pull/1094#discussion_r1218591790 From kcr at openjdk.org Mon Jun 5 22:53:04 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 5 Jun 2023 22:53:04 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v18] In-Reply-To: <90Qbdi_mFQbCH7sn5q1Jf_wJbWa9HK_QWDWyRoRAeGk=.350ee310-1ad4-4cd8-bb0f-67e5cf0084a1@github.com> References: <90Qbdi_mFQbCH7sn5q1Jf_wJbWa9HK_QWDWyRoRAeGk=.350ee310-1ad4-4cd8-bb0f-67e5cf0084a1@github.com> Message-ID: On Sun, 4 Jun 2023 18:48:29 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Unchanged line I ran an automated test job using your latest patch and all of the tests now pass. > Maybe it's possible to do a Java fix where the new Scene without size inherits the old Scene size? This way I think it possible to remove platform specific code such as the one I did and `_updateViewSize`. Hmm. That might be problematic. In any case, I don't want to go down that route to fix this bug. I have two questions on the current version of the fix: 1. Can you explain why the two tests had to be changed? Unless the tests in question really were buggy, and just getting luck before, the changes suggest a change in behavior that applications might notice and be bothered by. 2. Are you sure that on Linux, there are no cases where `_updateViewSize` needs to be implemented? Did you consider just leaving it as-is or would that have failed? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1577582572 From tsayao at openjdk.org Mon Jun 5 23:22:23 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 5 Jun 2023 23:22:23 GMT Subject: RFR: 8303038: Glass gtk3 sends scroll events with delta(x, y) = 0 [v10] In-Reply-To: <9H9NFSADpb1CL6zwN-Q8kdJUnId5CcSUo1KlBnTnP0Q=.41ca5b87-ae78-4ef9-89ac-c867a2517533@github.com> References: <9H9NFSADpb1CL6zwN-Q8kdJUnId5CcSUo1KlBnTnP0Q=.41ca5b87-ae78-4ef9-89ac-c867a2517533@github.com> Message-ID: > Simple fix to get the scroll deltas from GDK_SCROLL_SMOOTH. If we ignore this scroll event type, deltas are sent to java with the value equal to zero. > > Here's whats happening: > > We include all event masks, so when using gtk3 (>= 3.4.0) it includes `GDK_SMOOTH_SCROLL_MASK` meaning we receive duplicated events, one with `direction = GDK_SMOOTH_SCROLL_MASK` and other with "legacy" direction (UP/DOWN). > > When receiving the event corresponding to `GDK_SMOOTH_SCROLL_MASK` we ignored it causing it to send deltas (x,y) = 0. > > The fix now checks if `GDK_SMOOTH_SCROLL_MASK` is supported and uses it, also adding smooth scroll functionality. 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 42 additional commits since the last revision: - Merge branch 'master' into fix_scrolling - Listen only to smooth deltas - Merge branch 'master' into fix_scrolling - Remove print statement - Merge branch 'master' into fix_scrolling - Improve direction - Rename var - Fix direction - Fix for Ubuntu 20.04 - Fix scroll event - ... and 32 more: https://git.openjdk.org/jfx/compare/7a9c1b40...59a33014 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1044/files - new: https://git.openjdk.org/jfx/pull/1044/files/176f5a50..59a33014 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1044&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1044&range=08-09 Stats: 41111 lines in 875 files changed: 13073 ins; 3563 del; 24475 mod Patch: https://git.openjdk.org/jfx/pull/1044.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1044/head:pull/1044 PR: https://git.openjdk.org/jfx/pull/1044 From tsayao at openjdk.org Tue Jun 6 00:11:21 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 6 Jun 2023 00:11:21 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v19] In-Reply-To: References: Message-ID: <536PCCuZ0BN2p2Rv5NDP6fJ3fJgBtVmZuKxA0L1cV-c=.7630880f-f71b-475b-9fe3-b479547b4315@github.com> > I replicated the fix on #1054 on Linux. > > Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Use _updateViewSize ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1110/files - new: https://git.openjdk.org/jfx/pull/1110/files/e569a9f8..0809f527 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=18 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=17-18 Stats: 29 lines in 4 files changed: 18 ins; 8 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1110.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1110/head:pull/1110 PR: https://git.openjdk.org/jfx/pull/1110 From tsayao at openjdk.org Tue Jun 6 01:00:08 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 6 Jun 2023 01:00:08 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v18] In-Reply-To: References: <90Qbdi_mFQbCH7sn5q1Jf_wJbWa9HK_QWDWyRoRAeGk=.350ee310-1ad4-4cd8-bb0f-67e5cf0084a1@github.com> Message-ID: On Mon, 5 Jun 2023 22:50:00 GMT, Kevin Rushforth wrote: > I ran an automated test job using your latest patch and all of the tests now pass. > > > Maybe it's possible to do a Java fix where the new Scene without size inherits the old Scene size? This way I think it possible to remove platform specific code such as the one I did and `_updateViewSize`. > > Hmm. That might be problematic. In any case, I don't want to go down that route to fix this bug. > > I have two questions on the current version of the fix: > > 1. Can you explain why the two tests had to be changed? Unless the tests in question really were buggy, and just getting luck before, the changes suggest a change in behavior that applications might notice and be bothered by. > > 2. Are you sure that on Linux, there are no cases where `_updateViewSize` needs to be implemented? Did you consider just leaving it as-is or would that have failed? I changed it to use `_updateViewSize` so it's compatible with other platforms. I'm gathering some information to answer about the test changes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1577740976 From tsayao at openjdk.org Tue Jun 6 01:09:36 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 6 Jun 2023 01:09:36 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v20] In-Reply-To: References: Message-ID: > I replicated the fix on #1054 on Linux. > > Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Insert copyright ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1110/files - new: https://git.openjdk.org/jfx/pull/1110/files/0809f527..89a77e96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=19 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=18-19 Stats: 26 lines in 1 file changed: 26 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1110.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1110/head:pull/1110 PR: https://git.openjdk.org/jfx/pull/1110 From kpk at openjdk.org Tue Jun 6 05:48:05 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 6 Jun 2023 05:48:05 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v9] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: On Mon, 5 Jun 2023 17:12:41 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Add out of bound check for insertion index > > FYI, I've added "Enter Text" button to Text/TextFlow pages in the Monkey Tester > https://github.com/andy-goryachev-oracle/MonkeyTest > > it might be easier to test various emojis and text strings with it. Thanks @andy-goryachev-oracle. I will check above mentioned issue. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1091#issuecomment-1577951375 From mhanl at openjdk.org Tue Jun 6 09:39:04 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 6 Jun 2023 09:39:04 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v7] In-Reply-To: <_cRT1w2QchXm5_KUdMpOjONs6weVvJ9A53cLzVAOrYU=.2de6eca4-d1ae-43c0-89c3-af7db1fddbf9@github.com> References: <_cRT1w2QchXm5_KUdMpOjONs6weVvJ9A53cLzVAOrYU=.2de6eca4-d1ae-43c0-89c3-af7db1fddbf9@github.com> Message-ID: <7EJorwI4LAcD4KMiNv2YLPHk8l3SRAt0lP-u7ImBzZQ=.b3cc2977-8c8c-45f8-88f3-46fb12dc8aa9@github.com> On Mon, 15 May 2023 16:12:10 GMT, Andy Goryachev wrote: >> Fixed a memory leak in TreeTableView by reverting to register**Listener (which is ok in this particular situation) - the leak is specific to TreeTableRowSkin. >> >> Added a unit test. > > Andy Goryachev 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 17 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8307538.refresh > - review comments > - John is right > - review comments > - one more test case > - back to register listener > - weak lambdas are getting collected > - removed monkey tester changes > - Merge remote-tracking branch 'origin/master' into 8307538.refresh > - whitespace > - ... and 7 more: https://git.openjdk.org/jfx/compare/55028a61...f68de127 modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 117: > 115: TreeTableView treeTableView = getSkinnable().getTreeTableView(); > 116: if (treeTableView == null) { > 117: registerInvalidationListener(getSkinnable().treeTableViewProperty(), (x) -> { One question here: Why does this prevent the leak but the ListenerHelper does not? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1219289806 From kpk at openjdk.org Tue Jun 6 09:50:10 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 6 Jun 2023 09:50:10 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v9] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: On Mon, 5 Jun 2023 15:46:00 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Add out of bound check for insertion index > > tests/system/src/test/java/test/robot/javafx/scene/TextFlowSurrogatePairInsertionIndexTest.java line 151: > >> 149: private void addMultipleEmojis() { >> 150: Util.runAndWait(() -> { >> 151: text = new Text("??????"); > > Both new code (the last commit) and the old code (previous commit) fail this test if the text string is the following sequence: > ?????? > \u261d\ud83c\udfff\u261d\ud83c\udfff\u261d\ud83c\udfff > > I've tried it with jdk19 and jdk20.0.1 (the latter contains a BreakInterator change [JDK-8291660](https://bugs.openjdk.org/browse/JDK-8291660) that alters its handling of grapheme clusters. > > Exception: > > java.lang.AssertionError: expected:<0> but was:<1> > at org.junit.Assert.fail(Assert.java:89) > at org.junit.Assert.failNotEquals(Assert.java:835) > at org.junit.Assert.assertEquals(Assert.java:647) > at org.junit.Assert.assertEquals(Assert.java:633) > at test.robot.javafx.scene.TextFlowSurrogatePairInsertionIndexTest.testTextFlowInsertionIndexUsingMultipleEmojis(TextFlowSurrogatePairInsertionIndexTest.java:216) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)... This case is same as the one which we saw with red heart as the emoji sequence mentioned here is also a U+FE0F Variation Selector-16 character. Since it exhibits different behavior in different platforms we decided to remove it. I compared the insertion index calculated for these emojis with the insertion index calculated for red heart emoji. The insertion index calculated looks to be correct for the above given emojis. It is considered as 2 characters if color is also present else it is considered as single character. For me it is giving correct caret position as well in the Monkey tester. I found strange behavior when I tried to add heart emojis (with and without color) along with the `CLUSTERS` variable present in Monkey Tester so that it gets displayed when Rich Text option is selected. When `CLUSTERS = "?????"`, emojis are displayed properly. image When `CLUSTERS = "????????????????";`, following sequence is displayed. image This looks like a separate issue. Please let me know your thoughts on this. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1219305318 From kcr at openjdk.org Tue Jun 6 14:06:08 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Jun 2023 14:06:08 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v18] In-Reply-To: References: <90Qbdi_mFQbCH7sn5q1Jf_wJbWa9HK_QWDWyRoRAeGk=.350ee310-1ad4-4cd8-bb0f-67e5cf0084a1@github.com> Message-ID: <18C90tKvwVgTrWuQ3TFhuovrhNa6xKx8hYoXy5kPc50=.4f2cd1c2-dc71-41af-a20a-4223950e4d0b@github.com> On Tue, 6 Jun 2023 00:57:20 GMT, Thiago Milczarek Sayao wrote: > I changed it to use `_updateViewSize` so it's compatible with other platforms. As it turns out, I was looking at your incremental diff and (mistakenly) thought that `_updateViewSize` was in the current mainline code base and that you had removed it, which is why I asked about it. I now see that what happened is that the initial version of your PR had added it, and a later version had reverted that addition. And your most recent version added it back in. I don't mind either way, so if you think it's cleaner to implement `_updateViewSize` on Linux (even though today it's only implemented on Windows), that's OK. If you want to revert this latest addition of that method, that's OK, too. > I'm gathering some information to answer about the test changes. Thanks. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1578830605 From angorya at openjdk.org Tue Jun 6 15:59:04 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jun 2023 15:59:04 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v7] In-Reply-To: <7EJorwI4LAcD4KMiNv2YLPHk8l3SRAt0lP-u7ImBzZQ=.b3cc2977-8c8c-45f8-88f3-46fb12dc8aa9@github.com> References: <_cRT1w2QchXm5_KUdMpOjONs6weVvJ9A53cLzVAOrYU=.2de6eca4-d1ae-43c0-89c3-af7db1fddbf9@github.com> <7EJorwI4LAcD4KMiNv2YLPHk8l3SRAt0lP-u7ImBzZQ=.b3cc2977-8c8c-45f8-88f3-46fb12dc8aa9@github.com> Message-ID: On Tue, 6 Jun 2023 09:36:37 GMT, Marius Hanl wrote: >> Andy Goryachev 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 17 additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into 8307538.refresh >> - review comments >> - John is right >> - review comments >> - one more test case >> - back to register listener >> - weak lambdas are getting collected >> - removed monkey tester changes >> - Merge remote-tracking branch 'origin/master' into 8307538.refresh >> - whitespace >> - ... and 7 more: https://git.openjdk.org/jfx/compare/c419be41...f68de127 > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 117: > >> 115: TreeTableView treeTableView = getSkinnable().getTreeTableView(); >> 116: if (treeTableView == null) { >> 117: registerInvalidationListener(getSkinnable().treeTableViewProperty(), (x) -> { > > One question here: Why does this prevent the leak but the ListenerHelper does not? The difference is that registerInvalidationListener() adds a weak listener, while ListenerHelper adds a strong listener. It is possible to use ListenerHelper here, at the expense of more complicated code since we'd need to explicitly disconnect the listener when tableViewProperty value gets set. Another solution would involve adding a method to add a weak listener to the ListenerHelper to avoid explicit cleanup, or Go back to the original code which used register/unregister*Listener **in this particular case**. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1219912085 From duke at openjdk.org Tue Jun 6 16:36:46 2023 From: duke at openjdk.org (Daniel) Date: Tue, 6 Jun 2023 16:36:46 GMT Subject: RFR: JDK-8298104: NPE on synchronizeSceneNodes() In-Reply-To: References: Message-ID: On Wed, 3 May 2023 11:46:50 GMT, Daniel wrote: > A null pointer exception occurs on the ScenePulseListener when iterating through the dirty node list. > A null check is needed on the node before calling node.getScene(). > > The error occurs occasionally and causes the application to crash. > > Issue: [JDK-8298104: NPE on synchronizeSceneNodes()](https://bugs.openjdk.org/browse/JDK-8298104) [https://oca.opensource.oracle.com/api/v1/oca-requests/12557/documents/12517/download](https://oca.opensource.oracle.com/api/v1/oca-requests/12557/documents/12517/download) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1123#issuecomment-1532894525 From mhanl at openjdk.org Tue Jun 6 17:23:11 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 6 Jun 2023 17:23:11 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v7] In-Reply-To: <_cRT1w2QchXm5_KUdMpOjONs6weVvJ9A53cLzVAOrYU=.2de6eca4-d1ae-43c0-89c3-af7db1fddbf9@github.com> References: <_cRT1w2QchXm5_KUdMpOjONs6weVvJ9A53cLzVAOrYU=.2de6eca4-d1ae-43c0-89c3-af7db1fddbf9@github.com> Message-ID: On Mon, 15 May 2023 16:12:10 GMT, Andy Goryachev wrote: >> Fixed a memory leak in TreeTableView by reverting to register**Listener (which is ok in this particular situation) - the leak is specific to TreeTableRowSkin. >> >> Added a unit test. > > Andy Goryachev 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 17 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8307538.refresh > - review comments > - John is right > - review comments > - one more test case > - back to register listener > - weak lambdas are getting collected > - removed monkey tester changes > - Merge remote-tracking branch 'origin/master' into 8307538.refresh > - whitespace > - ... and 7 more: https://git.openjdk.org/jfx/compare/657d563d...f68de127 Looks good to me. ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1129#pullrequestreview-1465712675 From mhanl at openjdk.org Tue Jun 6 17:23:14 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 6 Jun 2023 17:23:14 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v7] In-Reply-To: References: <_cRT1w2QchXm5_KUdMpOjONs6weVvJ9A53cLzVAOrYU=.2de6eca4-d1ae-43c0-89c3-af7db1fddbf9@github.com> <7EJorwI4LAcD4KMiNv2YLPHk8l3SRAt0lP-u7ImBzZQ=.b3cc2977-8c8c-45f8-88f3-46fb12dc8aa9@github.com> Message-ID: On Tue, 6 Jun 2023 15:56:45 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 117: >> >>> 115: TreeTableView treeTableView = getSkinnable().getTreeTableView(); >>> 116: if (treeTableView == null) { >>> 117: registerInvalidationListener(getSkinnable().treeTableViewProperty(), (x) -> { >> >> One question here: Why does this prevent the leak but the ListenerHelper does not? > > The difference is that registerInvalidationListener() adds a weak listener, while ListenerHelper adds a strong listener. > > It is possible to use ListenerHelper here, at the expense of more complicated code since we'd need to explicitly disconnect the listener when tableViewProperty value gets set. > > Another solution would involve adding a method to add a weak listener to the ListenerHelper to avoid explicit cleanup, or > > Go back to the original code which used register/unregister*Listener **in this particular case**. Okay, makes sense. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1220038627 From angorya at openjdk.org Tue Jun 6 18:06:09 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jun 2023 18:06:09 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v7] In-Reply-To: <_cRT1w2QchXm5_KUdMpOjONs6weVvJ9A53cLzVAOrYU=.2de6eca4-d1ae-43c0-89c3-af7db1fddbf9@github.com> References: <_cRT1w2QchXm5_KUdMpOjONs6weVvJ9A53cLzVAOrYU=.2de6eca4-d1ae-43c0-89c3-af7db1fddbf9@github.com> Message-ID: On Mon, 15 May 2023 16:12:10 GMT, Andy Goryachev wrote: >> Fixed a memory leak in TreeTableView by reverting to register**Listener (which is ok in this particular situation) - the leak is specific to TreeTableRowSkin. >> >> Added a unit test. > > Andy Goryachev 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 17 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8307538.refresh > - review comments > - John is right > - review comments > - one more test case > - back to register listener > - weak lambdas are getting collected > - removed monkey tester changes > - Merge remote-tracking branch 'origin/master' into 8307538.refresh > - whitespace > - ... and 7 more: https://git.openjdk.org/jfx/compare/a610a8a7...f68de127 thank you all for your feedback and effort! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1129#issuecomment-1579223878 From angorya at openjdk.org Tue Jun 6 18:06:10 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jun 2023 18:06:10 GMT Subject: Integrated: 8307538: Memory leak in TreeTableView when calling refresh In-Reply-To: References: Message-ID: On Fri, 5 May 2023 21:55:48 GMT, Andy Goryachev wrote: > Fixed a memory leak in TreeTableView by reverting to register**Listener (which is ok in this particular situation) - the leak is specific to TreeTableRowSkin. > > Added a unit test. This pull request has now been integrated. Changeset: 17ed2e73 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/17ed2e73256c50116b5e9404093aa51c0b4c1b9a Stats: 78 lines in 2 files changed: 56 ins; 11 del; 11 mod 8307538: Memory leak in TreeTableView when calling refresh Reviewed-by: kcr, aghaisas, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1129 From jvos at openjdk.org Tue Jun 6 18:35:07 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 6 Jun 2023 18:35:07 GMT Subject: RFR: 8309001: Allow building JavaFX on Linux/riscv64 [v2] In-Reply-To: <7P006bObWwZn_RS8jOFt0YM1bEM91TPQljvJYDcyGPk=.ae16d69f-7925-45fe-9d82-e2b76322f6cb@github.com> References: <7P006bObWwZn_RS8jOFt0YM1bEM91TPQljvJYDcyGPk=.ae16d69f-7925-45fe-9d82-e2b76322f6cb@github.com> Message-ID: <_P1IdXj7sA0s7zS_06v0C5MUTCaKVaMjWzMLh-7-TQM=.cd987486-2148-49bb-8a62-018770ff38af@github.com> On Fri, 2 Jun 2023 15:56:23 GMT, Eric Long wrote: >> RISC-V is a new free and open-source ISA that is being widely adopted in the recent years. Currently WebKit is ready for riscv64, and only minor changes is needed to support the platform. > > Eric Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8309001: Add Linux/riscv64 support looks good. In general, I think the concept of the split between the build.gradle and the separate platform-specific files in buildSrc (e.g. linux.gradle) needs some rethinking as we are increasing the already huge build.gradle. But that should not be part of this PR, hence +1. ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1146#pullrequestreview-1465830693 From angorya at openjdk.org Tue Jun 6 20:18:11 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jun 2023 20:18:11 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v9] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: On Tue, 6 Jun 2023 09:46:53 GMT, Karthik P K wrote: >> tests/system/src/test/java/test/robot/javafx/scene/TextFlowSurrogatePairInsertionIndexTest.java line 151: >> >>> 149: private void addMultipleEmojis() { >>> 150: Util.runAndWait(() -> { >>> 151: text = new Text("??????"); >> >> Both new code (the last commit) and the old code (previous commit) fail this test if the text string is the following sequence: >> ?????? >> \u261d\ud83c\udfff\u261d\ud83c\udfff\u261d\ud83c\udfff >> >> I've tried it with jdk19 and jdk20.0.1 (the latter contains a BreakInterator change [JDK-8291660](https://bugs.openjdk.org/browse/JDK-8291660) that alters its handling of grapheme clusters. >> >> Exception: >> >> java.lang.AssertionError: expected:<0> but was:<1> >> at org.junit.Assert.fail(Assert.java:89) >> at org.junit.Assert.failNotEquals(Assert.java:835) >> at org.junit.Assert.assertEquals(Assert.java:647) >> at org.junit.Assert.assertEquals(Assert.java:633) >> at test.robot.javafx.scene.TextFlowSurrogatePairInsertionIndexTest.testTextFlowInsertionIndexUsingMultipleEmojis(TextFlowSurrogatePairInsertionIndexTest.java:216) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:578) >> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) >> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) >> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) >> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) >> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) >> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) >> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) >> at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) >> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) >> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) >> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) >> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) >> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) >> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) >> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) >> at org.junit.runners.Pare... > > This case is same as the one which we saw with red heart as the emoji sequence mentioned here is also a U+FE0F Variation Selector-16 character. Since it exhibits different behavior in different platforms we decided to remove it. > > I compared the insertion index calculated for these emojis with the insertion index calculated for red heart emoji. The insertion index calculated looks to be correct for the above given emojis. It is considered as 2 characters if color is also present else it is considered as single character. > For me it is giving correct caret position as well in the Monkey tester. > > I found strange behavior when I tried to add heart emojis (with and without color) along with the `CLUSTERS` variable present in Monkey Tester so that it gets displayed when Rich Text option is selected. > When `CLUSTERS = "?????"`, emojis are displayed properly. > image > > When `CLUSTERS = "????????????????";`, following sequence is displayed. > image > > This looks like a separate issue. Please let me know your thoughts on this. @karthikpandelu : 1. you are right, multiple symbols and a failed test are due to lack of proper handling of grapheme clusters in fx. I don't think we have a ticket, so created JDK-8309565 for that 2. your latest fix uncovered a problem in my RichTextArea code, so thank you! The new code passes all my tests in the MonkeyTester and RichTextArea. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1220270289 From angorya at openjdk.org Tue Jun 6 20:18:08 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jun 2023 20:18:08 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v9] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: On Mon, 5 Jun 2023 11:16:52 GMT, Karthik P K wrote: >> Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. >> >> Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. >> The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. >> >> Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add out of bound check for insertion index Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1091#pullrequestreview-1466006786 From angorya at openjdk.org Tue Jun 6 22:47:25 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jun 2023 22:47:25 GMT Subject: RFR: 8194704: Text/TextFlow hitTest() javadoc Message-ID: correcting javadoc (index) -> (hit info) ------------- Commit messages: - link - 8194704: Text/TextFlow hitTest() javadoc Changes: https://git.openjdk.org/jfx/pull/1149/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1149&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8194704 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1149.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1149/head:pull/1149 PR: https://git.openjdk.org/jfx/pull/1149 From almatvee at openjdk.org Tue Jun 6 23:09:05 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 6 Jun 2023 23:09:05 GMT Subject: RFR: 8304290: Some JNI calls made without checking exceptions in media [v2] In-Reply-To: References: Message-ID: On Mon, 5 Jun 2023 20:55:30 GMT, Kevin Rushforth wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8304290: Some JNI calls made without checking exceptions in media [v2] > > modules/javafx.media/src/main/native/jfxmedia/jni/JavaPlayerEventDispatcher.cpp line 199: > >> 197: } >> 198: >> 199: pEnv->DeleteLocalRef(jmessage); > > This needs to be moved inside the previous `if` block. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1094#discussion_r1220513572 From almatvee at openjdk.org Tue Jun 6 23:20:10 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 6 Jun 2023 23:20:10 GMT Subject: RFR: 8304290: Some JNI calls made without checking exceptions in media [v2] In-Reply-To: References: Message-ID: On Mon, 5 Jun 2023 21:04:15 GMT, Kevin Rushforth wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8304290: Some JNI calls made without checking exceptions in media [v2] > > modules/javafx.media/src/main/native/jfxmedia/jni/JniUtils.cpp line 59: > >> 57: } >> 58: // This shouldn't happen... >> 59: return; > > Don't you still need this `return`? I moved it under `if (env->ExceptionCheck() || klass != NULL)`, but this check is incorrect and it should be `if (env->ExceptionCheck() || klass == NULL)`. I fixed it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1094#discussion_r1220523650 From almatvee at openjdk.org Tue Jun 6 23:27:19 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 6 Jun 2023 23:27:19 GMT Subject: RFR: 8304290: Some JNI calls made without checking exceptions in media [v3] In-Reply-To: References: Message-ID: > - Added missing exception checks for JNI calls. > - Improved JNI error checking by checking for both exception and return value. > - Minor code clean up. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8304290: Some JNI calls made without checking exceptions in media [v3] ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1094/files - new: https://git.openjdk.org/jfx/pull/1094/files/582daf7e..aad51ea7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1094&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1094&range=01-02 Stats: 10 lines in 2 files changed: 1 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1094.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1094/head:pull/1094 PR: https://git.openjdk.org/jfx/pull/1094 From almatvee at openjdk.org Tue Jun 6 23:27:31 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 6 Jun 2023 23:27:31 GMT Subject: RFR: 8304290: Some JNI calls made without checking exceptions in media [v2] In-Reply-To: References: Message-ID: On Wed, 31 May 2023 22:36:54 GMT, Alexander Matveev wrote: >> - Added missing exception checks for JNI calls. >> - Improved JNI error checking by checking for both exception and return value. >> - Minor code clean up. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8304290: Some JNI calls made without checking exceptions in media [v2] 8304290: Some JNI calls made without checking exceptions in media [v3] - Fixed latest comments. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1094#issuecomment-1579589967 From kpk at openjdk.org Wed Jun 7 05:04:10 2023 From: kpk at openjdk.org (Karthik P K) Date: Wed, 7 Jun 2023 05:04:10 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v9] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: On Tue, 6 Jun 2023 20:14:41 GMT, Andy Goryachev wrote: >> This case is same as the one which we saw with red heart as the emoji sequence mentioned here is also a U+FE0F Variation Selector-16 character. Since it exhibits different behavior in different platforms we decided to remove it. >> >> I compared the insertion index calculated for these emojis with the insertion index calculated for red heart emoji. The insertion index calculated looks to be correct for the above given emojis. It is considered as 2 characters if color is also present else it is considered as single character. >> For me it is giving correct caret position as well in the Monkey tester. >> >> I found strange behavior when I tried to add heart emojis (with and without color) along with the `CLUSTERS` variable present in Monkey Tester so that it gets displayed when Rich Text option is selected. >> When `CLUSTERS = "?????"`, emojis are displayed properly. >> image >> >> When `CLUSTERS = "????????????????";`, following sequence is displayed. >> image >> >> This looks like a separate issue. Please let me know your thoughts on this. > > @karthikpandelu : > 1. you are right, multiple symbols and a failed test are due to lack of proper handling of grapheme clusters in fx. I don't think we have a ticket, so created JDK-8309565 for that > 2. your latest fix uncovered a problem in my RichTextArea code, so thank you! > > The new code passes all my tests in the MonkeyTester and RichTextArea. Than you @andy-goryachev-oracle for the detailed review and feedback. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1220851313 From kpk at openjdk.org Wed Jun 7 05:42:04 2023 From: kpk at openjdk.org (Karthik P K) Date: Wed, 7 Jun 2023 05:42:04 GMT Subject: RFR: 8194704: Text/TextFlow hitTest() javadoc In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 22:41:48 GMT, Andy Goryachev wrote: > correcting javadoc (index) -> (hit info) Looks good to me. ------------- Marked as reviewed by kpk (Committer). PR Review: https://git.openjdk.org/jfx/pull/1149#pullrequestreview-1466648955 From kcr at openjdk.org Wed Jun 7 11:40:05 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 7 Jun 2023 11:40:05 GMT Subject: RFR: 8194704: Text/TextFlow hitTest() javadoc In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 22:41:48 GMT, Andy Goryachev wrote: > correcting javadoc (index) -> (hit info) Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1149#pullrequestreview-1467421288 From duke at openjdk.org Wed Jun 7 11:58:11 2023 From: duke at openjdk.org (Eric Long) Date: Wed, 7 Jun 2023 11:58:11 GMT Subject: RFR: 8309001: Allow building JavaFX on Linux/riscv64 [v3] In-Reply-To: References: Message-ID: > RISC-V is a new free and open-source ISA that is being widely adopted in the recent years. Currently WebKit is ready for riscv64, and only minor changes is needed to support the platform. Eric Long has updated the pull request incrementally with one additional commit since the last revision: 8309001: Allow building JavaFX on Linux/riscv64 Reviewed-by: kcr, jvos ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1146/files - new: https://git.openjdk.org/jfx/pull/1146/files/040d1d71..74bed4e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1146&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1146&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1146.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1146/head:pull/1146 PR: https://git.openjdk.org/jfx/pull/1146 From duke at openjdk.org Wed Jun 7 11:58:12 2023 From: duke at openjdk.org (Eric Long) Date: Wed, 7 Jun 2023 11:58:12 GMT Subject: Integrated: 8309001: Allow building JavaFX on Linux/riscv64 In-Reply-To: References: Message-ID: On Tue, 30 May 2023 17:39:57 GMT, Eric Long wrote: > RISC-V is a new free and open-source ISA that is being widely adopted in the recent years. Currently WebKit is ready for riscv64, and only minor changes is needed to support the platform. This pull request has now been integrated. Changeset: 883c4e02 Author: Eric Long Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/883c4e029945d5d7d7ae2103c4c50518115aa4b5 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 8309001: Allow building JavaFX on Linux/riscv64 Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.org/jfx/pull/1146 From kevin.rushforth at oracle.com Wed Jun 7 12:12:00 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 7 Jun 2023 05:12:00 -0700 Subject: Result: New OpenJFX Committer: Lukasz Kostyra Message-ID: <4bec5e37-5d84-e436-bb93-e53622c77101@oracle.com> Voting for Lukasz Kostyra [1] to OpenJFX Committer [2] is now closed. Yes: 8 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] https://openjdk.org/census#lkostyra [2] https://mail.openjdk.org/pipermail/openjfx-dev/2023-May/040739.html From kcr at openjdk.org Wed Jun 7 15:32:10 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 7 Jun 2023 15:32:10 GMT Subject: RFR: 8304290: Some JNI calls made without checking exceptions in media [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 23:27:19 GMT, Alexander Matveev wrote: >> - Added missing exception checks for JNI calls. >> - Improved JNI error checking by checking for both exception and return value. >> - Minor code clean up. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8304290: Some JNI calls made without checking exceptions in media [v3] Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1094#pullrequestreview-1467997769 From angorya at openjdk.org Wed Jun 7 16:21:02 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Jun 2023 16:21:02 GMT Subject: Integrated: 8194704: Text/TextFlow hitTest() javadoc In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 22:41:48 GMT, Andy Goryachev wrote: > correcting javadoc (index) -> (hit info) This pull request has now been integrated. Changeset: 6a159e91 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/6a159e91e0ff698c2dc4731a6171b565abeb1bdf Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8194704: Text/TextFlow hitTest() javadoc Reviewed-by: kpk, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1149 From mhanl at openjdk.org Wed Jun 7 21:04:04 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 7 Jun 2023 21:04:04 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow Message-ID: This PR does two small improvements to `VirtualFlow`. Until now, the `VirtualFlow` sometimes called the `computeHeight` or `computeWidth` methods, although a fixed cell size is set and we therefore don't need to call those method (and never should do, as we may don't get the expected result and mix computed sizes with the fixed cell size). Added tests that fail before and pass now. They check that the `computeHeight` or `computeWidth` (non vertical flow) are never called when a fixed cell size is set. ------------- Commit messages: - JDK-8309470: Potential performance improvements in VirtualFlow Changes: https://git.openjdk.org/jfx/pull/1150/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1150&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309470 Stats: 126 lines in 2 files changed: 101 ins; 13 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/1150.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1150/head:pull/1150 PR: https://git.openjdk.org/jfx/pull/1150 From sproket at videotron.ca Wed Jun 7 23:26:35 2023 From: sproket at videotron.ca (Dan Howard) Date: Wed, 7 Jun 2023 19:26:35 -0400 Subject: Result: New OpenJFX Committer: Lukasz Kostyra In-Reply-To: <4bec5e37-5d84-e436-bb93-e53622c77101@oracle.com> References: <4bec5e37-5d84-e436-bb93-e53622c77101@oracle.com> Message-ID: <45a948ad-de1d-80e1-53c5-24a7c899f243@videotron.ca> Congratz Lukasz! On 6/7/2023 8:12 AM, Kevin Rushforth wrote: > Voting for Lukasz Kostyra [1] to OpenJFX Committer [2] is now closed. > > Yes: 8 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Lazy Consensus, this is > sufficient to approve the nomination. > > -- Kevin > > [1] https://openjdk.org/census#lkostyra > > [2] https://mail.openjdk.org/pipermail/openjfx-dev/2023-May/040739.html > From angorya at openjdk.org Thu Jun 8 00:04:01 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jun 2023 00:04:01 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow In-Reply-To: References: Message-ID: On Wed, 7 Jun 2023 20:59:01 GMT, Marius Hanl wrote: > This PR does two small improvements to `VirtualFlow`. > Until now, the `VirtualFlow` sometimes called the `computeHeight` or `computeWidth` methods, although a fixed cell size is set and we therefore don't need to call those method (and never should do, as we may don't get the expected result and mix computed sizes with the fixed cell size). > > Added tests that fail before and pass now. They check that the `computeHeight` or `computeWidth` (non vertical flow) are never called when a fixed cell size is set. modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1954: > 1952: * Gets the breadth of a specific cell > 1953: */ > 1954: double getCellBreadth(T cell) { is there a possibility of introducing a runtime errors? modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1530: > 1528: @Test > 1529: public void testComputeHeightShouldNotBeCalledWhenFixedCellSizeIsSet() { > 1530: int cellSize = 24; magic number. cellSize=94 fails the test, unless line 1555 changed to `flow.resize(3000, 3000);` cellSize=4 is ok. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1579: > 1577: @Test > 1578: public void testComputeWidthShouldNotBeCalledWhenFixedCellSizeIsSet() { > 1579: int cellSize = 24; magic number. setting cell size to 44 fails the test. cellSize=4 is ok. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1150#discussion_r1222292196 PR Review Comment: https://git.openjdk.org/jfx/pull/1150#discussion_r1222269418 PR Review Comment: https://git.openjdk.org/jfx/pull/1150#discussion_r1222268654 From angorya at openjdk.org Thu Jun 8 00:09:54 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jun 2023 00:09:54 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow In-Reply-To: References: Message-ID: <6IRHgSDVBHB4OzVSIHGKwYSLBYku2nff3cQjDvtPY64=.af445f58-8a06-4cc0-a9b5-e8190f15f401@github.com> On Wed, 7 Jun 2023 20:59:01 GMT, Marius Hanl wrote: > This PR does two small improvements to `VirtualFlow`. > Until now, the `VirtualFlow` sometimes called the `computeHeight` or `computeWidth` methods, although a fixed cell size is set and we therefore don't need to call those method (and never should do, as we may don't get the expected result and mix computed sizes with the fixed cell size). > > Added tests that fail before and pass now. They check that the `computeHeight` or `computeWidth` (non vertical flow) are never called when a fixed cell size is set. I don't see any ill effects in the MonkeyTester. There is still a bit of lag with 10,000,000 row model, same as before. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1150#issuecomment-1581676505 From mhanl at openjdk.org Thu Jun 8 06:51:02 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Jun 2023 06:51:02 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow In-Reply-To: References: Message-ID: On Thu, 8 Jun 2023 00:01:02 GMT, Andy Goryachev wrote: >> This PR does two small improvements to `VirtualFlow`. >> Until now, the `VirtualFlow` sometimes called the `computeHeight` or `computeWidth` methods, although a fixed cell size is set and we therefore don't need to call those method (and never should do, as we may don't get the expected result and mix computed sizes with the fixed cell size). >> >> Added tests that fail before and pass now. They check that the `computeHeight` or `computeWidth` (non vertical flow) are never called when a fixed cell size is set. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1954: > >> 1952: * Gets the breadth of a specific cell >> 1953: */ >> 1954: double getCellBreadth(T cell) { > > is there a possibility of introducing a runtime errors? No, this is just cosmetic and more correct as every cell inside the VirtualFlow is bound to the type parameter T. > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1579: > >> 1577: @Test >> 1578: public void testComputeWidthShouldNotBeCalledWhenFixedCellSizeIsSet() { >> 1579: int cellSize = 24; > > magic number. setting cell size to 44 fails the test. cellSize=4 is ok. not per se a magic number in this context, as the VirtualFlow is resized to 300. So 13 cells fit inside it with this fixed cell size. Making it bigger will of course fail the test below. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1150#discussion_r1222531553 PR Review Comment: https://git.openjdk.org/jfx/pull/1150#discussion_r1222530483 From mhanl at openjdk.org Thu Jun 8 06:59:25 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Jun 2023 06:59:25 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow [v2] In-Reply-To: References: Message-ID: > This PR does two small improvements to `VirtualFlow`. > Until now, the `VirtualFlow` sometimes called the `computeHeight` or `computeWidth` methods, although a fixed cell size is set and we therefore don't need to call those method (and never should do, as we may don't get the expected result and mix computed sizes with the fixed cell size). > > Added tests that fail before and pass now. They check that the `computeHeight` or `computeWidth` (non vertical flow) are never called when a fixed cell size is set. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: JDK-8309470: Test: Resize VirtualFlow by cellSize * 10 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1150/files - new: https://git.openjdk.org/jfx/pull/1150/files/98db3f73..2bdfb1f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1150&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1150&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1150.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1150/head:pull/1150 PR: https://git.openjdk.org/jfx/pull/1150 From mhanl at openjdk.org Thu Jun 8 06:59:25 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Jun 2023 06:59:25 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow [v2] In-Reply-To: References: Message-ID: On Thu, 8 Jun 2023 06:46:28 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1579: >> >>> 1577: @Test >>> 1578: public void testComputeWidthShouldNotBeCalledWhenFixedCellSizeIsSet() { >>> 1579: int cellSize = 24; >> >> magic number. setting cell size to 44 fails the test. cellSize=4 is ok. > > not per se a magic number in this context, as the VirtualFlow is resized to 300. > So 13 cells fit inside it with this fixed cell size. Making it bigger will of course fail the test below. Just changed the resize method to be `cellSize * 10`, so it is less of a magic number in that case. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1150#discussion_r1222539247 From mhanl at openjdk.org Thu Jun 8 06:59:45 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Jun 2023 06:59:45 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow In-Reply-To: <6IRHgSDVBHB4OzVSIHGKwYSLBYku2nff3cQjDvtPY64=.af445f58-8a06-4cc0-a9b5-e8190f15f401@github.com> References: <6IRHgSDVBHB4OzVSIHGKwYSLBYku2nff3cQjDvtPY64=.af445f58-8a06-4cc0-a9b5-e8190f15f401@github.com> Message-ID: On Thu, 8 Jun 2023 00:07:20 GMT, Andy Goryachev wrote: > I don't see any ill effects in the MonkeyTester. There is still a bit of lag with 10,000,000 row model, same as before. Yeah for me as well. This is a very minor improvement and actually with this PR the following assertion is now true: When a fixed cell size is set, the `computeXXX` methods from the cell will never be called. This is also what you would expect, as before the fixed cell size may be mixed with computed sizes in some circumstances. If you e.g. subclass `TableRow` and do heavy computation inside the `computeXXX` methods, those will not be called. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1150#issuecomment-1581992580 From mhanl at openjdk.org Thu Jun 8 07:18:22 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Jun 2023 07:18:22 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow [v3] In-Reply-To: References: Message-ID: > This PR does two small improvements to `VirtualFlow`. > Until now, the `VirtualFlow` sometimes called the `computeHeight` or `computeWidth` methods, although a fixed cell size is set and we therefore don't need to call those method (and never should do, as we may don't get the expected result and mix computed sizes with the fixed cell size). > > Added tests that fail before and pass now. They check that the `computeHeight` or `computeWidth` (non vertical flow) are never called when a fixed cell size is set. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: JDK-8309470: Improved Tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1150/files - new: https://git.openjdk.org/jfx/pull/1150/files/2bdfb1f4..4527e652 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1150&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1150&range=01-02 Stats: 28 lines in 1 file changed: 19 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1150.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1150/head:pull/1150 PR: https://git.openjdk.org/jfx/pull/1150 From mhanl at openjdk.org Thu Jun 8 07:22:07 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Jun 2023 07:22:07 GMT Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with nested nodes (hbox) and pseudo-class in style sheet [v6] In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 07:14:07 GMT, John Hendrikx wrote: >> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. >> >> In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. >> >> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. >> >> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. >> >> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. >> >> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. >> >> Although the test case above was extreme, this change should have positive effects for most applications. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Avoid using Lambda in ImmutablePseudoClassSetsCache.of() Note: This PR needs a merge/rebase. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1076#issuecomment-1582025950 From jhendrikx at openjdk.org Thu Jun 8 07:25:59 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 8 Jun 2023 07:25:59 GMT Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with nested nodes (hbox) and pseudo-class in style sheet [v6] In-Reply-To: References: Message-ID: On Thu, 8 Jun 2023 07:19:35 GMT, Marius Hanl wrote: > Note: This PR needs a merge/rebase. Yes, I will get around to it this weekend ------------- PR Comment: https://git.openjdk.org/jfx/pull/1076#issuecomment-1582034862 From kpk at openjdk.org Thu Jun 8 13:45:56 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 8 Jun 2023 13:45:56 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow [v3] In-Reply-To: References: Message-ID: On Thu, 8 Jun 2023 07:18:22 GMT, Marius Hanl wrote: >> This PR does two small improvements to `VirtualFlow`. >> Until now, the `VirtualFlow` sometimes called the `computeHeight` or `computeWidth` methods, although a fixed cell size is set and we therefore don't need to call those method (and never should do, as we may don't get the expected result and mix computed sizes with the fixed cell size). >> >> Added tests that fail before and pass now. They check that the `computeHeight` or `computeWidth` (non vertical flow) are never called when a fixed cell size is set. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8309470: Improved Tests Tested the changes in MacOS 13.3.1, I'm seeing failure of `testComputeHeightShouldNotBeCalledWhenFixedCellSizeIsSet` and `testComputeWidthShouldNotBeCalledWhenFixedCellSizeIsSet` with and without the changes of this PR. VirtualFlowTest > testComputeHeightShouldNotBeCalledWhenFixedCellSizeIsSet FAILED java.lang.AssertionError: expected:<24.0> but was:<1337.0> at org.junit.Assert.fail(Assert.java:89) at org.junit.Assert.failNotEquals(Assert.java:835) at org.junit.Assert.assertEquals(Assert.java:555) at org.junit.Assert.assertEquals(Assert.java:685) at test.javafx.scene.control.skin.VirtualFlowTest.testComputeHeightShouldNotBeCalledWhenFixedCellSizeIsSet(VirtualFlowTest.java:1566) VirtualFlowTest > testComputeWidthShouldNotBeCalledWhenFixedCellSizeIsSet FAILED java.lang.AssertionError: expected:<24.0> but was:<1337.0> at org.junit.Assert.fail(Assert.java:89) at org.junit.Assert.failNotEquals(Assert.java:835) at org.junit.Assert.assertEquals(Assert.java:555) at org.junit.Assert.assertEquals(Assert.java:685) at test.javafx.scene.control.skin.VirtualFlowTest.testComputeWidthShouldNotBeCalledWhenFixedCellSizeIsSet(VirtualFlowTest.java:1622) Changes requested by kpk (Committer). modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 3065: > 3063: } > 3064: > 3065: // if we have a valid cell, we can populate the cache Do we need this comment now? modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1542: > 1540: @Override > 1541: protected double computeMinHeight(double width) { > 1542: return 1337; Can we add a final variable for this number since it is repeated many times? ------------- Changes requested by kpk (Committer). PR Review: https://git.openjdk.org/jfx/pull/1150#pullrequestreview-1469946391 PR Review: https://git.openjdk.org/jfx/pull/1150#pullrequestreview-1469948040 PR Review Comment: https://git.openjdk.org/jfx/pull/1150#discussion_r1223061740 PR Review Comment: https://git.openjdk.org/jfx/pull/1150#discussion_r1223062537 From dollj at xsinet.co.za Thu Jun 8 14:04:46 2023 From: dollj at xsinet.co.za (Jurgen Doll) Date: Thu, 08 Jun 2023 16:04:46 +0200 Subject: Comment for JDK-8289115 - Touch events are not dispatched after upgrade to FX17 Message-ID: Hi Could someone please add the following lines as comment to the issue JDK-8289115 (https://bugs.openjdk.org/browse/JDK-8289115) Thank you very much. @Praveen please have another look at Capture.pptx and you'll see that only MouseEvents are being fired and NO TouchEvents. The test case illustrates exactly what the reporter describes as being the problem. Note that this appears to be device INdependent, so any TouchScreen running Windows with either touch or pen/stylus and no TouchEvents are fired after jfx17-ea+2-win. This bug is a direct result of fixing JDK-8249737 RuntimeException: Too many touch points reported. (https://bugs.openjdk.java.net/browse/JDK-8249737) Please reopen both of these issues. Thanks, Jurgen From angorya at openjdk.org Thu Jun 8 15:26:56 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jun 2023 15:26:56 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow [v3] In-Reply-To: References: Message-ID: On Thu, 8 Jun 2023 07:18:22 GMT, Marius Hanl wrote: >> This PR does two small improvements to `VirtualFlow`. >> Until now, the `VirtualFlow` sometimes called the `computeHeight` or `computeWidth` methods, although a fixed cell size is set and we therefore don't need to call those method (and never should do, as we may don't get the expected result and mix computed sizes with the fixed cell size). >> >> Added tests that fail before and pass now. They check that the `computeHeight` or `computeWidth` (non vertical flow) are never called when a fixed cell size is set. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8309470: Improved Tests Strange, I don't see failures in VirtualFlowTest on macOS 13.3.1(a) in Eclipse. @karthikpandelu could you make sure you have no modified files in the repository and try doing a full build? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1150#issuecomment-1582814294 From mhanl at openjdk.org Thu Jun 8 15:51:07 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Jun 2023 15:51:07 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow [v4] In-Reply-To: References: Message-ID: > This PR does two small improvements to `VirtualFlow`. > Until now, the `VirtualFlow` sometimes called the `computeHeight` or `computeWidth` methods, although a fixed cell size is set and we therefore don't need to call those method (and never should do, as we may don't get the expected result and mix computed sizes with the fixed cell size). > > Added tests that fail before and pass now. They check that the `computeHeight` or `computeWidth` (non vertical flow) are never called when a fixed cell size is set. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: JDK-8309470: Remove unused import and comment ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1150/files - new: https://git.openjdk.org/jfx/pull/1150/files/4527e652..486c7254 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1150&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1150&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1150.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1150/head:pull/1150 PR: https://git.openjdk.org/jfx/pull/1150 From angorya at openjdk.org Thu Jun 8 15:51:13 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jun 2023 15:51:13 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow [v3] In-Reply-To: References: Message-ID: On Thu, 8 Jun 2023 15:43:00 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1542: >> >>> 1540: @Override >>> 1541: protected double computeMinHeight(double width) { >>> 1542: return 1337; >> >> Can we add a final variable for this number since it is repeated many times? > > It is just an arbitrary number for testing and only used for those two methods. > Not sure if it is worth it (it can be basically every number but should not be the fixed cell size) yeah, I don't think it's that important. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1150#discussion_r1223232725 From mhanl at openjdk.org Thu Jun 8 15:51:12 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Jun 2023 15:51:12 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow [v3] In-Reply-To: References: Message-ID: On Thu, 8 Jun 2023 13:41:56 GMT, Karthik P K wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8309470: Improved Tests > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 3065: > >> 3063: } >> 3064: >> 3065: // if we have a valid cell, we can populate the cache > > Do we need this comment now? no, it doesn't add anything useful to the code ? > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 1542: > >> 1540: @Override >> 1541: protected double computeMinHeight(double width) { >> 1542: return 1337; > > Can we add a final variable for this number since it is repeated many times? It is just an arbitrary number for testing and only used for those two methods. Not sure if it is worth it (it can be basically every number but should not be the fixed cell size) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1150#discussion_r1223232327 PR Review Comment: https://git.openjdk.org/jfx/pull/1150#discussion_r1223231530 From mhanl at openjdk.org Thu Jun 8 15:59:13 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Jun 2023 15:59:13 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow [v5] In-Reply-To: References: Message-ID: > This PR does two small improvements to `VirtualFlow`. > Until now, the `VirtualFlow` sometimes called the `computeHeight` or `computeWidth` methods, although a fixed cell size is set and we therefore don't need to call those method (and never should do, as we may don't get the expected result and mix computed sizes with the fixed cell size). > > Added tests that fail before and pass now. They check that the `computeHeight` or `computeWidth` (non vertical flow) are never called when a fixed cell size is set. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: JDK-8309470: Added fail tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1150/files - new: https://git.openjdk.org/jfx/pull/1150/files/486c7254..07de1e1a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1150&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1150&range=03-04 Stats: 80 lines in 1 file changed: 78 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1150.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1150/head:pull/1150 PR: https://git.openjdk.org/jfx/pull/1150 From mhanl at openjdk.org Thu Jun 8 15:59:13 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Jun 2023 15:59:13 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow [v3] In-Reply-To: References: Message-ID: On Thu, 8 Jun 2023 13:41:04 GMT, Karthik P K wrote: > Tested the changes in MacOS 13.3.1, I'm seeing failure ... I added two more test that directly fail if those methods are called. You will get a better stacktrace from them. If this issue still appears, please paste it here. :) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1150#issuecomment-1582890398 From kpk at openjdk.org Thu Jun 8 17:46:44 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 8 Jun 2023 17:46:44 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow [v5] In-Reply-To: References: Message-ID: <-bpw2RhVEzZqJ0LdwL7BHUij704MM49IG-QRycmuq8E=.aa2c6638-6baf-4710-9202-61f916c78842@github.com> On Thu, 8 Jun 2023 15:59:13 GMT, Marius Hanl wrote: >> This PR does two small improvements to `VirtualFlow`. >> Until now, the `VirtualFlow` sometimes called the `computeHeight` or `computeWidth` methods, although a fixed cell size is set and we therefore don't need to call those method (and never should do, as we may don't get the expected result and mix computed sizes with the fixed cell size). >> >> Added tests that fail before and pass now. They check that the `computeHeight` or `computeWidth` (non vertical flow) are never called when a fixed cell size is set. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8309470: Added fail tests All the tests added here passes with the fix and fails without it. No issues now. Could have been some problem from my end. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1150#issuecomment-1583083165 From angorya at openjdk.org Thu Jun 8 17:55:30 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jun 2023 17:55:30 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow [v5] In-Reply-To: References: Message-ID: On Thu, 8 Jun 2023 15:59:13 GMT, Marius Hanl wrote: >> This PR does two small improvements to `VirtualFlow`. >> Until now, the `VirtualFlow` sometimes called the `computeHeight` or `computeWidth` methods, although a fixed cell size is set and we therefore don't need to call those method (and never should do, as we may don't get the expected result and mix computed sizes with the fixed cell size). >> >> Added tests that fail before and pass now. They check that the `computeHeight` or `computeWidth` (non vertical flow) are never called when a fixed cell size is set. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8309470: Added fail tests lgtm ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1150#pullrequestreview-1470496391 From angorya at openjdk.org Thu Jun 8 17:55:33 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jun 2023 17:55:33 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow [v5] In-Reply-To: References: Message-ID: <8oFf4Xd9pkFA5gB1L5lo2E0A_U9zw9zBdRZurRLBuuQ=.8aeb1ba6-7c19-4dab-93d2-462f5f351f0c@github.com> On Thu, 8 Jun 2023 06:47:44 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1954: >> >>> 1952: * Gets the breadth of a specific cell >>> 1953: */ >>> 1954: double getCellBreadth(T cell) { >> >> is there a possibility of introducing runtime errors? > > No, this is just cosmetic and more correct as every cell inside the VirtualFlow is bound to the type parameter T. this method should have been private. I see no other callers outside of VirtualFlow, so it's probably safe. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1150#discussion_r1223375875 From thiago.sayao at gmail.com Thu Jun 8 18:06:44 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 8 Jun 2023 15:06:44 -0300 Subject: How to run an app headless? Message-ID: Hi, I'm building javafx with: ./gradlew -PincludeMonocle build And trying to test with: java @/home/tsayao/jfx/build/run.args -Dglass.platform=Monocle -Dmonocle.platform=Headless -Dprism.order=sw WindowTest.java But it seems monocle was not included: java.lang.ClassNotFoundException: com.sun.glass.ui.monocle.MonoclePlatformFactory Any obvious mistake? -- Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From kpk at openjdk.org Thu Jun 8 18:24:48 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 8 Jun 2023 18:24:48 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow [v5] In-Reply-To: References: Message-ID: <9-JoZMVUaDo15vNGUlut4YlrQpxnWzrJ_yTt0UvTY-E=.4de8d782-efce-43ae-ad87-1e2102f25a07@github.com> On Thu, 8 Jun 2023 15:59:13 GMT, Marius Hanl wrote: >> This PR does two small improvements to `VirtualFlow`. >> Until now, the `VirtualFlow` sometimes called the `computeHeight` or `computeWidth` methods, although a fixed cell size is set and we therefore don't need to call those method (and never should do, as we may don't get the expected result and mix computed sizes with the fixed cell size). >> >> Added tests that fail before and pass now. They check that the `computeHeight` or `computeWidth` (non vertical flow) are never called when a fixed cell size is set. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8309470: Added fail tests lgtm ------------- Marked as reviewed by kpk (Committer). PR Review: https://git.openjdk.org/jfx/pull/1150#pullrequestreview-1470537987 From kevin.rushforth at oracle.com Thu Jun 8 18:54:10 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 8 Jun 2023 11:54:10 -0700 Subject: How to run an app headless? In-Reply-To: References: Message-ID: An easier way would be to use the shims classes, which is what "gradle test" uses. Monocle is included with the shims even without needing to specify anything. Try something like this: gradle shims java @build/testrun.args -Dglass.platform=Monocle -Dmonocle.platform=Headless WindowTest.java -- Kevin On 6/8/2023 11:06 AM, Thiago Milczarek Say?o wrote: > Hi, > > I'm building javafx with: > ./gradlew -PincludeMonocle build > > And trying to test with: > java @/home/tsayao/jfx/build/run.args -Dglass.platform=Monocle > -Dmonocle.platform=Headless -Dprism.order=sw WindowTest.java > > But it seems monocle was not included: > java.lang.ClassNotFoundException: > com.sun.glass.ui.monocle.MonoclePlatformFactory > > Any obvious mistake? > > -- Thiago From mhanl at openjdk.org Thu Jun 8 19:01:53 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Jun 2023 19:01:53 GMT Subject: RFR: 8309470: Potential performance improvements in VirtualFlow [v5] In-Reply-To: <-bpw2RhVEzZqJ0LdwL7BHUij704MM49IG-QRycmuq8E=.aa2c6638-6baf-4710-9202-61f916c78842@github.com> References: <-bpw2RhVEzZqJ0LdwL7BHUij704MM49IG-QRycmuq8E=.aa2c6638-6baf-4710-9202-61f916c78842@github.com> Message-ID: On Thu, 8 Jun 2023 17:44:21 GMT, Karthik P K wrote: > All the tests added here passes with the fix and fails without it. No issues now. Could have been some problem from my end. Alright, thanks for the feedback! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1150#issuecomment-1583173255 From mhanl at openjdk.org Thu Jun 8 19:05:48 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Jun 2023 19:05:48 GMT Subject: Integrated: 8309470: Potential performance improvements in VirtualFlow In-Reply-To: References: Message-ID: On Wed, 7 Jun 2023 20:59:01 GMT, Marius Hanl wrote: > This PR does two small improvements to `VirtualFlow`. > Until now, the `VirtualFlow` sometimes called the `computeHeight` or `computeWidth` methods, although a fixed cell size is set and we therefore don't need to call those method (and never should do, as we may don't get the expected result and mix computed sizes with the fixed cell size). > > Added tests that fail before and pass now. They check that the `computeHeight` or `computeWidth` (non vertical flow) are never called when a fixed cell size is set. This pull request has now been integrated. Changeset: 9ad0e908 Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/9ad0e908088373aaa7220fc98ef5625d8f9ff6a4 Stats: 217 lines in 2 files changed: 191 ins; 14 del; 12 mod 8309470: Potential performance improvements in VirtualFlow Reviewed-by: kpk, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1150 From tsayao at openjdk.org Thu Jun 8 20:08:57 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 8 Jun 2023 20:08:57 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v20] In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 01:09:36 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Insert copyright It seems Headless monocle was not focusing the window before, so this is why tests were passing before (focus was not being accounted). I've attached a simple `FocusTest` on JBS that prints to the console when Stage/TextField are focused. It does not print anything before this change. `java -Dglass.platform=Monocle -Dmonocle.platform=Headless -Dprism.order=sw @build/testrun.args FocusTest.java` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1583268444 From angorya at openjdk.org Thu Jun 8 21:40:48 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jun 2023 21:40:48 GMT Subject: RFR: 8306648: Update the JavaDocs to show the NEW section and DEPRECATED versions [v2] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 11:39:24 GMT, Nir Lisker wrote: >> Adds the javadoc commands to generate the NEW page and to be able to select versions in the DEPRECATED page. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Auto-detect latest version I am somewhat divided on which version to start with. On one hand, it makes sense to use last LTS version (or previous, if the current one is also LTS), so 17. On the other hand, most of the "supported" fx apps are probably still on java8, so that is the most logical version, especially considering the task of upgrading said applications. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1109#issuecomment-1583397203 From mhanl at openjdk.org Thu Jun 8 21:56:50 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Jun 2023 21:56:50 GMT Subject: RFR: 8306648: Update the JavaDocs to show the NEW section and DEPRECATED versions [v2] In-Reply-To: References: Message-ID: <_ZIjWqwdk6y5m6VDatnq_aVme3nUtFqb_OAJixTS4Ys=.59fb079b-5dfe-423c-ba0c-586fc1ec47c9@github.com> On Thu, 8 Jun 2023 21:38:02 GMT, Andy Goryachev wrote: > I am somewhat divided on which version to start with. On one hand, it makes sense to use last LTS version (or previous, if the current one is also LTS), so 17. I think we should either start from 9 or 11. Depending on the source, Java 11 is used more often than 8, which probably also means JavaFX 11+ is used more often than 8. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1109#issuecomment-1583439219 From angorya at openjdk.org Thu Jun 8 22:33:48 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jun 2023 22:33:48 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v5] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 18:07:53 GMT, Martin Fox wrote: >> The algorithm in `KeyCharacterCombination.match` relies on the call `Toolkit.getKeyCodeForChar` which is difficult to implement correctly. It defies the way most keyboard API?s work and no platform has got it right yet. In particular the Mac and Linux implementations have to resort to a brute-force approach which monitors keystrokes to learn the relationship between keys and characters. >> >> This PR introduces an alternative mechanism which directly asks the platform whether a given key can generate a specific character. It also allows the platform to attach identifying key information to each KeyEvent to make it easier to answer the question (much, much easier). >> >> This is mostly dumb plumbing. On the front-end there?s a new call `View.notifyKeyEx` that takes an additional platform-specific `hardwareCode` parameter. It also returns a boolean indicating whether the event was consumed or not so I can fix JDK-8087863. If you want to follow the path visit the files in this order: >> >> View.java >> GlassViewEventHandler.java >> TKSceneListener.java >> Scene.java >> >> The `KeyEvent` class has been expanded with an additional `hardwareCode` member that can only be accessed internally. See KeyEvent.java and KeyEventHelper.java. >> >> On the back-end `KeyCharacterCombination.match` calls a new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the `KeyEvent` information and sends it on to the Application. The default implementation falls back to the old `getKeyCodeForChar` call but platform specific Applications can send it on to the native glass code. >> >> KeyCharacterCombination.java >> Toolkit.java >> QuantumToolkit.java >> Application.java >> GtkApplication.java >> >> The glass code can use the `hardwareCode` to answer the question directly. It also has enough information to fall back on the old `getKeyCodeForChar` logic while also enabling the keypad (a common complaint is that Ctrl+?+? only works on the main keyboard and not the keypad, see JDK-8090275). >> >> This PR improves the situation for key events generated by keystrokes. Manually constructed key events won?t work any better or worse than they already do. Based on the bug database I don't think this is an issue. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Updating classpath for Eclipse users looks good to me, as far as I can tell. needs a second reviewer familiar with the native linux code. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/694#pullrequestreview-1470855325 From tsayao at openjdk.org Fri Jun 9 00:05:51 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 9 Jun 2023 00:05:51 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v5] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 18:07:53 GMT, Martin Fox wrote: >> The algorithm in `KeyCharacterCombination.match` relies on the call `Toolkit.getKeyCodeForChar` which is difficult to implement correctly. It defies the way most keyboard API?s work and no platform has got it right yet. In particular the Mac and Linux implementations have to resort to a brute-force approach which monitors keystrokes to learn the relationship between keys and characters. >> >> This PR introduces an alternative mechanism which directly asks the platform whether a given key can generate a specific character. It also allows the platform to attach identifying key information to each KeyEvent to make it easier to answer the question (much, much easier). >> >> This is mostly dumb plumbing. On the front-end there?s a new call `View.notifyKeyEx` that takes an additional platform-specific `hardwareCode` parameter. It also returns a boolean indicating whether the event was consumed or not so I can fix JDK-8087863. If you want to follow the path visit the files in this order: >> >> View.java >> GlassViewEventHandler.java >> TKSceneListener.java >> Scene.java >> >> The `KeyEvent` class has been expanded with an additional `hardwareCode` member that can only be accessed internally. See KeyEvent.java and KeyEventHelper.java. >> >> On the back-end `KeyCharacterCombination.match` calls a new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the `KeyEvent` information and sends it on to the Application. The default implementation falls back to the old `getKeyCodeForChar` call but platform specific Applications can send it on to the native glass code. >> >> KeyCharacterCombination.java >> Toolkit.java >> QuantumToolkit.java >> Application.java >> GtkApplication.java >> >> The glass code can use the `hardwareCode` to answer the question directly. It also has enough information to fall back on the old `getKeyCodeForChar` logic while also enabling the keypad (a common complaint is that Ctrl+?+? only works on the main keyboard and not the keypad, see JDK-8090275). >> >> This PR improves the situation for key events generated by keystrokes. Manually constructed key events won?t work any better or worse than they already do. Based on the bug database I don't think this is an issue. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Updating classpath for Eclipse users modules/javafx.graphics/src/main/java/com/sun/javafx/tk/TKSceneListener.java line 68: > 66: * > 67: * @param keyEvent The key event > 68: * @return true iff the event was consumed There's an extra f in "if". ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/694#discussion_r1223656752 From tsayao at openjdk.org Fri Jun 9 00:25:54 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 9 Jun 2023 00:25:54 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v5] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 18:07:53 GMT, Martin Fox wrote: >> The algorithm in `KeyCharacterCombination.match` relies on the call `Toolkit.getKeyCodeForChar` which is difficult to implement correctly. It defies the way most keyboard API?s work and no platform has got it right yet. In particular the Mac and Linux implementations have to resort to a brute-force approach which monitors keystrokes to learn the relationship between keys and characters. >> >> This PR introduces an alternative mechanism which directly asks the platform whether a given key can generate a specific character. It also allows the platform to attach identifying key information to each KeyEvent to make it easier to answer the question (much, much easier). >> >> This is mostly dumb plumbing. On the front-end there?s a new call `View.notifyKeyEx` that takes an additional platform-specific `hardwareCode` parameter. It also returns a boolean indicating whether the event was consumed or not so I can fix JDK-8087863. If you want to follow the path visit the files in this order: >> >> View.java >> GlassViewEventHandler.java >> TKSceneListener.java >> Scene.java >> >> The `KeyEvent` class has been expanded with an additional `hardwareCode` member that can only be accessed internally. See KeyEvent.java and KeyEventHelper.java. >> >> On the back-end `KeyCharacterCombination.match` calls a new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the `KeyEvent` information and sends it on to the Application. The default implementation falls back to the old `getKeyCodeForChar` call but platform specific Applications can send it on to the native glass code. >> >> KeyCharacterCombination.java >> Toolkit.java >> QuantumToolkit.java >> Application.java >> GtkApplication.java >> >> The glass code can use the `hardwareCode` to answer the question directly. It also has enough information to fall back on the old `getKeyCodeForChar` logic while also enabling the keypad (a common complaint is that Ctrl+?+? only works on the main keyboard and not the keypad, see JDK-8090275). >> >> This PR improves the situation for key events generated by keystrokes. Manually constructed key events won?t work any better or worse than they already do. Based on the bug database I don't think this is an issue. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Updating classpath for Eclipse users modules/javafx.graphics/src/main/java/com/sun/glass/ui/View.java line 974: > 972: } > 973: > 974: // Returns true iff event was consumed There are some places where it's written "iff", I'm not sure if it's intentional or a typo. tests/manual/events/KeyCharacterCombinationTest.java line 41: > 39: > 40: public static void main(String[] args) { > 41: Application.launch(args); Would be nice to add the class to `launch`, `Application.launch(KeyCharacterCombinationTest.class, args);` so it can be run as: `java @build/run.args tests/manual/events/KeyCharacterCombinationTest.java` tests/manual/events/KeyCharacterCombinationTest.java line 45: > 43: > 44: @Override > 45: public void start(Stage stage) { I started the test app but was unsure how to test it. Maybe add a header text that explains how a successful test should go. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/694#discussion_r1223665772 PR Review Comment: https://git.openjdk.org/jfx/pull/694#discussion_r1223667093 PR Review Comment: https://git.openjdk.org/jfx/pull/694#discussion_r1223667647 From duke at openjdk.org Fri Jun 9 00:29:50 2023 From: duke at openjdk.org (Martin Fox) Date: Fri, 9 Jun 2023 00:29:50 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v3] In-Reply-To: References: <0LZJQIwWTfmg6C04_iZYqXLg5dlkIm1-PLekNJq4eyI=.f500948f-8f84-48cd-8503-d0b4e716db86@github.com> Message-ID: On Tue, 25 Apr 2023 18:36:45 GMT, Andy Goryachev wrote: >> @andy-goryachev-oracle My highest priorities are #425 (Mac) and the Java code in this PR. I'll get it switched over to Windows as soon as possible so we have a complete implementation of the new key event pipeline to review. Third on the list is the Linux Robot code (#718) but the documentation of that API is, um, scattered so I don't expect the review to go all that quickly. > > Thank you for clarifications, @beldenfox . @andy-goryachev-oracle My apologies, I really should have cleaned this PR up weeks ago when the bridgekeeper bot flagged it. The portion of this PR that is platform-agnostic was also submitted in PR #1126. In that PR I incorporated all of the feedback you already provided (and thank you for that). I re-submitted all of this with a Windows front- and back-end because at the time Windows was the only platform with working Robot code so the changes could be tested (the manual app is included in #1126 as well as #425). I was also hoping that the review would go faster on Windows since no one seems to have much familiarity with the Linux API's except me and @tsayao (and the documentation is wretched). I've already done a bit of cleanup over in #1126 that conflict with the changes here (I just renamed some routines). I've kept this PR around so the Linux-specific code can be reviewed but I should probably switch it over to Draft. And the Linux Robot code needs to be reviewed and integrated first to enable testing (#718). ------------- PR Comment: https://git.openjdk.org/jfx/pull/694#issuecomment-1583664102 From duke at openjdk.org Fri Jun 9 00:38:49 2023 From: duke at openjdk.org (Martin Fox) Date: Fri, 9 Jun 2023 00:38:49 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v5] In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 00:18:46 GMT, Thiago Milczarek Sayao wrote: >> Martin Fox has updated the pull request incrementally with one additional commit since the last revision: >> >> Updating classpath for Eclipse users > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/View.java line 974: > >> 972: } >> 973: >> 974: // Returns true iff event was consumed > > There are some places where it's written "iff", I'm not sure if it's intentional or a typo. iff is an abbreviation for "if and only if". It's a bit formal but I noticed it was used in other internal API comments and JavaDocs. I think I removed all of these when I resubmitted this code as part of #1126. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/694#discussion_r1223682272 From tsayao at openjdk.org Fri Jun 9 00:41:46 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 9 Jun 2023 00:41:46 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v3] In-Reply-To: References: <0LZJQIwWTfmg6C04_iZYqXLg5dlkIm1-PLekNJq4eyI=.f500948f-8f84-48cd-8503-d0b4e716db86@github.com> Message-ID: On Tue, 25 Apr 2023 18:36:45 GMT, Andy Goryachev wrote: >> @andy-goryachev-oracle My highest priorities are #425 (Mac) and the Java code in this PR. I'll get it switched over to Windows as soon as possible so we have a complete implementation of the new key event pipeline to review. Third on the list is the Linux Robot code (#718) but the documentation of that API is, um, scattered so I don't expect the review to go all that quickly. > > Thank you for clarifications, @beldenfox . @andy-goryachev-oracle Linux code looks correct to me. ------------- PR Comment: https://git.openjdk.org/jfx/pull/694#issuecomment-1583679185 From jhendrikx at openjdk.org Fri Jun 9 01:12:18 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Jun 2023 01:12:18 GMT Subject: RFR: JDK-8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v8] In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> Message-ID: > This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. > > # Behavior > > |Listener...|ExpressionHelper|ListenerManager| > |---|---|---| > |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| > |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| > |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| > > ## Nested notifications: > > | |ExpressionHelper|ListenerManager| > |---|---|---| > |Type|Depth first (call stack increases for each nested level)|(same)| > |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| > |Vetoing Possible?|No|Yes| > |Old Value correctness|Only for listeners called before listeners making nested changes|Always| > > # Performance > > |Listener|ExpressionHelper|ListenerManager| > |---|---|---| > |Addition|Array based, append in empty slot, resize as needed|(same)| > |Removal|Array based, shift array, resize as needed|(same)| > |Addition during notification|Array is copied, removing collected WeakListeneres in the process|Tracked (append at end)| > |Removal during notification|As above|Entry is `null`ed| > |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| > |Notifying Invalidation Listeners|1 ns each|(same)| > |Notifying Change Listeners|1 ns each (*)|2-3 ns each| > > (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values > > # Memory Use > > Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. > > |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| > |---|---|---|---| > |No Listeners|none|none|none| > |Single InvalidationListener|16 bytes overhead|none|none| > |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| > |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)| > > # About nested changes > > Nested changes are simply changes that are made to a property that is currently in the process of notifying its listeners. This all occurs on the same thread, and a nested change is nothing more th... John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Prevent removal of weak listeners during unlock ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1081/files - new: https://git.openjdk.org/jfx/pull/1081/files/b97c574a..09feb52c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=06-07 Stats: 176 lines in 2 files changed: 156 ins; 10 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1081.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081 PR: https://git.openjdk.org/jfx/pull/1081 From jhendrikx at openjdk.org Fri Jun 9 01:33:27 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Jun 2023 01:33:27 GMT Subject: RFR: JDK-8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v9] In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> Message-ID: > This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. > > # Behavior > > |Listener...|ExpressionHelper|ListenerManager| > |---|---|---| > |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| > |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| > |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| > > ## Nested notifications: > > | |ExpressionHelper|ListenerManager| > |---|---|---| > |Type|Depth first (call stack increases for each nested level)|(same)| > |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| > |Vetoing Possible?|No|Yes| > |Old Value correctness|Only for listeners called before listeners making nested changes|Always| > > # Performance > > |Listener|ExpressionHelper|ListenerManager| > |---|---|---| > |Addition|Array based, append in empty slot, resize as needed|(same)| > |Removal|Array based, shift array, resize as needed|(same)| > |Addition during notification|Array is copied, removing collected WeakListeneres in the process|Tracked (append at end)| > |Removal during notification|As above|Entry is `null`ed| > |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| > |Notifying Invalidation Listeners|1 ns each|(same)| > |Notifying Change Listeners|1 ns each (*)|2-3 ns each| > > (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values > > # Memory Use > > Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. > > |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| > |---|---|---|---| > |No Listeners|none|none|none| > |Single InvalidationListener|16 bytes overhead|none|none| > |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| > |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)| > > # About nested changes > > Nested changes are simply changes that are made to a property that is currently in the process of notifying its listeners. This all occurs on the same thread, and a nested change is nothing more th... John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Merge remote-tracking branch 'upstream/master' into feature/nested-emission-with-correct-old-values - Prevent removal of weak listeners during unlock - Use an overridable method to store latest value - Merge the recursive notification loop code Made loop in ListenerList slightly more generic to allow merging the logic in OldValueCachingListenerList and ListenerList; performance impact seems minimal - Small bug fix in OldValueCachingListenerList - Added a test case to detect and avoid this problem - Improve doc - Move listener call code to ListListenerBase - Improve generics on ObservableValueBase - Improve generics - Fix incorrect import - ... and 14 more: https://git.openjdk.org/jfx/compare/8110f548...a9c488b9 ------------- Changes: https://git.openjdk.org/jfx/pull/1081/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=08 Stats: 4355 lines in 39 files changed: 4192 ins; 7 del; 156 mod Patch: https://git.openjdk.org/jfx/pull/1081.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081 PR: https://git.openjdk.org/jfx/pull/1081 From jhendrikx at openjdk.org Fri Jun 9 02:00:17 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Jun 2023 02:00:17 GMT Subject: RFR: JDK-8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v10] In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> Message-ID: > This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. > > # Behavior > > |Listener...|ExpressionHelper|ListenerManager| > |---|---|---| > |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| > |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| > |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| > > ## Nested notifications: > > | |ExpressionHelper|ListenerManager| > |---|---|---| > |Type|Depth first (call stack increases for each nested level)|(same)| > |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| > |Vetoing Possible?|No|Yes| > |Old Value correctness|Only for listeners called before listeners making nested changes|Always| > > # Performance > > |Listener|ExpressionHelper|ListenerManager| > |---|---|---| > |Addition|Array based, append in empty slot, resize as needed|(same)| > |Removal|Array based, shift array, resize as needed|(same)| > |Addition during notification|Array is copied, removing collected WeakListeneres in the process|Tracked (append at end)| > |Removal during notification|As above|Entry is `null`ed| > |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| > |Notifying Invalidation Listeners|1 ns each|(same)| > |Notifying Change Listeners|1 ns each (*)|2-3 ns each| > > (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values > > # Memory Use > > Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. > > |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| > |---|---|---|---| > |No Listeners|none|none|none| > |Single InvalidationListener|16 bytes overhead|none|none| > |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| > |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)| > > # About nested changes > > Nested changes are simply changes that are made to a property that is currently in the process of notifying its listeners. This all occurs on the same thread, and a nested change is nothing more th... John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix merge ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1081/files - new: https://git.openjdk.org/jfx/pull/1081/files/a9c488b9..9ac121b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1081.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081 PR: https://git.openjdk.org/jfx/pull/1081 From jdv at openjdk.org Fri Jun 9 05:25:08 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 9 Jun 2023 05:25:08 GMT Subject: RFR: 8309508: Possible memory leak in JPEG image loader Message-ID: On code inspection it is revealed that in jpegloader.c->decompressIndirect() we are allocating memory for "scanline_ptr", but if we error_exit() from jpeg_read_scanlines() we are not releasing this memory. Added release of "scanline_ptr" with NULL check at appropriate places. As part of this fix also added RELEASE_ARRAYS() call for stream/pixel buffer in all cases where we move back to Java code. Its difficult to create definite pass/fail regression test for memory leak, added noreg-hard label in JBS. ------------- Commit messages: - 8309508: Possible memory leak in JPEG image loader Changes: https://git.openjdk.org/jfx/pull/1151/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1151&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309508 Stats: 14 lines in 1 file changed: 9 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1151.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1151/head:pull/1151 PR: https://git.openjdk.org/jfx/pull/1151 From duke at openjdk.org Fri Jun 9 05:59:48 2023 From: duke at openjdk.org (Fabian Wolter) Date: Fri, 9 Jun 2023 05:59:48 GMT Subject: RFR: 8087370: [odroid] Monocle: Touch is still broken on Odroid In-Reply-To: References: <8r1cERIcJeZVLWYcG3EqWV7zKEoDqtLLgqBVHlPIUyI=.9f7e72c8-de1a-49f6-9df2-8d6a5f46174a@github.com> Message-ID: On Fri, 29 Apr 2022 14:59:41 GMT, Alexander Scherbatiy wrote: >> There are sometimes multitouch events detected, when only a single touch should be detected under certain conditions. This lead to touch events on previous touch positions. >> >> The referenced bug is closed with "won't fix" with the justification it would be platform specific. But this is not correct. It affects all Linux platforms combined with a touch controller, which sends the touch events in an uncommon, but valid(!), order. >> >> We encountered this problem with the touch controller ILI2511 with firmware V6000_V1 in the Tianma display TM070JVHG33. This patch fixes the problem. It is the same patch attached to above bug report. > > The 8087370 includes [LinuxStatefulMultiTouchProcessor-fix-for-1.patch](https://bugs.openjdk.java.net/secure/attachment/50236/LinuxStatefulMultiTouchProcessor-fix-for-1.patch) to fix the first described case: > > 1. Consider you're touching the screen with two fingers, for example coordinates > of one point is ~100,100 and second point is ~200,200. While still touching around > the same points some events are reported with one or another point > to be either 100,200 or 200,100. > > Is it reproduced on your system as well? > > It relates to `8282104: Node zoom/rotate flickers on Raspberry Pi with Touchscreen` with fix #737 which suggests to not take LinuxInput.ABS_X/Y events into account for non zero slots instead just skipping them for all slots. Unfortunately, I can't afford time to burrow into the issue again for writing tests at the moment. @AlexanderScherbatiy is there any chance you can provide a test case? ------------- PR Comment: https://git.openjdk.org/jfx/pull/641#issuecomment-1584015830 From johan.vos at gluonhq.com Fri Jun 9 07:29:40 2023 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 9 Jun 2023 09:29:40 +0200 Subject: How to run an app headless? In-Reply-To: References: Message-ID: The monocle classes are not included in the default distributions/artifact. In our downloads on https://gluonhq.com/products/javafx/ we have specific SDK's that include the Monocle classes. Note that we currently don't have automated builds for Linux x86-64, since we use a devkit compiled from JDK-alike sources, see https://github.com/gluonhq/devtoolskit/ for more info. That devkit unfortunately doesn't yet compile some of the native classes in monocle. The usecase where Monocle is used because users want to run an app headless is something I see very often. And it works. However, Monocle isn't really created for this, as it is more a solution for embedded systems. I think there is real value in a separate, small, first-class Glass platform that works headless (at the same level as gtk/mac/win) and that is explicitly targeting running apps in headless mode. - Johan On Thu, Jun 8, 2023 at 8:07?PM Thiago Milczarek Say?o < thiago.sayao at gmail.com> wrote: > Hi, > > I'm building javafx with: > ./gradlew -PincludeMonocle build > > And trying to test with: > java @/home/tsayao/jfx/build/run.args -Dglass.platform=Monocle > -Dmonocle.platform=Headless -Dprism.order=sw WindowTest.java > > But it seems monocle was not included: > java.lang.ClassNotFoundException: > com.sun.glass.ui.monocle.MonoclePlatformFactory > > Any obvious mistake? > > -- Thiago > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.sayao at gmail.com Fri Jun 9 10:40:03 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Fri, 9 Jun 2023 07:40:03 -0300 Subject: How to run an app headless? In-Reply-To: References: Message-ID: Hi Johan, I just wanted to replicate a simple test outside of the testing system to see why the behavior change in focus is happening on https://github.com/openjdk/jfx/pull/1110 So the solution Kevin replied to in this email was enough. The fix for this PR seems to have focused the button that is used in the MouseEventFirerTest. testAnchorRight[0], so the testing values are different (because of the focus decoration shadow). Before the PR and the change made in https://bugs.openjdk.org/browse/JDK-8296621 the button does get focused, but when the test runs, values are not updated yet. It's weird because with the PR, focus does get a little bit delayed because it happens after the window is shown (makes sense to me to show and then focus). -- Thiago Em sex., 9 de jun. de 2023 ?s 04:29, Johan Vos escreveu: > The monocle classes are not included in the default > distributions/artifact. In our downloads on > https://gluonhq.com/products/javafx/ we have specific SDK's that include > the Monocle classes. Note that we currently don't have automated builds for > Linux x86-64, since we use a devkit compiled from JDK-alike sources, see > https://github.com/gluonhq/devtoolskit/ for more info. That devkit > unfortunately doesn't yet compile some of the native classes in monocle. > > The usecase where Monocle is used because users want to run an app > headless is something I see very often. And it works. However, Monocle > isn't really created for this, as it is more a solution for embedded > systems. > I think there is real value in a separate, small, first-class Glass > platform that works headless (at the same level as gtk/mac/win) and that is > explicitly targeting running apps in headless mode. > > - Johan > > > > > On Thu, Jun 8, 2023 at 8:07?PM Thiago Milczarek Say?o < > thiago.sayao at gmail.com> wrote: > >> Hi, >> >> I'm building javafx with: >> ./gradlew -PincludeMonocle build >> >> And trying to test with: >> java @/home/tsayao/jfx/build/run.args -Dglass.platform=Monocle >> -Dmonocle.platform=Headless -Dprism.order=sw WindowTest.java >> >> But it seems monocle was not included: >> java.lang.ClassNotFoundException: >> com.sun.glass.ui.monocle.MonoclePlatformFactory >> >> Any obvious mistake? >> >> -- Thiago >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.sayao at gmail.com Fri Jun 9 10:53:45 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Fri, 9 Jun 2023 07:53:45 -0300 Subject: Text Surrounding Message-ID: Hi Andy, I understand you're working on a Rich Text control. While working on IME (Input Method Editor) for Linux, I noticed that there is a feature called "surrounding" that it supports to give the IME information about the text being inputted. More info here: https://docs.gtk.org/gtk3/class.IMContext.html It works like this: When user is typing using an IME language, the underlying IME (for example https://github.com/tlwg/ibus-libthai) may ask the Toolkit for the surrounding text and it should reply with: https://docs.gtk.org/gtk3/method.IMContext.set_surrounding.html That contains: - The text - The length - The cursor position within the text So this way the underlying IME can provide accurate suggestions using the user context. That would be a nice feature to have but it requires some work to retrieve it from the text-based control. Just letting you know about this, it may be out of the scope of your rich text work for now. -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.sayao at gmail.com Fri Jun 9 11:02:54 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Fri, 9 Jun 2023 08:02:54 -0300 Subject: Intellij Idea project gradle import bug Message-ID: Hi, The systemTests module is not being correctly imported on Intellij, so I reported a bug here: https://youtrack.jetbrains.com/issue/IDEA-322108/Intellij-Idea-fails-to-import-JavaFx-gradle-project-correctly Just letting Idea users know. -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Fri Jun 9 12:00:06 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Jun 2023 12:00:06 GMT Subject: RFR: JDK-8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v11] In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> Message-ID: > This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. > > # Behavior > > |Listener...|ExpressionHelper|ListenerManager| > |---|---|---| > |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| > |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| > |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| > > ## Nested notifications: > > | |ExpressionHelper|ListenerManager| > |---|---|---| > |Type|Depth first (call stack increases for each nested level)|(same)| > |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| > |Vetoing Possible?|No|Yes| > |Old Value correctness|Only for listeners called before listeners making nested changes|Always| > > # Performance > > |Listener|ExpressionHelper|ListenerManager| > |---|---|---| > |Addition|Array based, append in empty slot, resize as needed|(same)| > |Removal|Array based, shift array, resize as needed|(same)| > |Addition during notification|Array is copied, removing collected WeakListeneres in the process|Tracked (append at end)| > |Removal during notification|As above|Entry is `null`ed| > |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| > |Notifying Invalidation Listeners|1 ns each|(same)| > |Notifying Change Listeners|1 ns each (*)|2-3 ns each| > > (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values > > # Memory Use > > Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. > > |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| > |---|---|---|---| > |No Listeners|none|none|none| > |Single InvalidationListener|16 bytes overhead|none|none| > |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| > |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)| > > # About nested changes > > Nested changes are simply changes that are made to a property that is currently in the process of notifying its listeners. This all occurs on the same thread, and a nested change is nothing more th... John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix generic warnings ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1081/files - new: https://git.openjdk.org/jfx/pull/1081/files/9ac121b8..b5db37e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=09-10 Stats: 10 lines in 1 file changed: 3 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1081.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081 PR: https://git.openjdk.org/jfx/pull/1081 From jhendrikx at openjdk.org Fri Jun 9 12:02:32 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Jun 2023 12:02:32 GMT Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with nested nodes (hbox) and pseudo-class in style sheet [v7] In-Reply-To: References: Message-ID: > This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. > > In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. > > Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. > > The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. > > The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. > > A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. > > Although the test case above was extreme, this change should have positive effects for most applications. John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() - Merge branch 'master' of https://git.openjdk.org/jfx into feature/immutable-pseudoclassstate - Fix another edge case in BitSet equals When arrays are not the same size, but there are no set bits in the ones the other set doesn't have, two bit sets can still be considered equal - Take element type into account for BitSet.equals() - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray - Removed faulty toArray implementations in PseudoClassState and StyleClassSet - Added test that verifies equals/hashCode for PseudoClassState respect Set contract now - Made getBits package private so it can't be inherited - Remove unused code - Ensure Match doesn't allow modification - Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy - Remove double call to getIndex - ... and 5 more: https://git.openjdk.org/jfx/compare/8110f548...4d2d6118 ------------- Changes: https://git.openjdk.org/jfx/pull/1076/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1076&range=06 Stats: 503 lines in 12 files changed: 286 ins; 146 del; 71 mod Patch: https://git.openjdk.org/jfx/pull/1076.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1076/head:pull/1076 PR: https://git.openjdk.org/jfx/pull/1076 From kcr at openjdk.org Fri Jun 9 12:38:58 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Jun 2023 12:38:58 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v14] In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 04:17:23 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: > > - Merge branch 'master' into allow-reproducible-builds > - Revert format of timestamp in version OPT field > - Merge branch 'master' into allow-reproducible-builds > > Include two commits that fix WebKit build failures on Windows and macOS: > > 8282359: Intermittent WebKit build failure on Windows: > C1090: PDB API call failed, error code 23 > 8286089: Intermittent WebKit build failure on macOS in JavaScriptCore > - Merge branch 'master' into allow-reproducible-builds > - Support JDK 17 GA or later for building JavaFX > - Merge branch 'master' into allow-reproducible-builds > - Add '--date' argument for deterministic JMOD files > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - Comment out 'jmod --date' until building on JDK 19 > > Support for the 'jmod --date' option was added to JDK 19 starting > with the 19+2 early-access build, and it was backported to JDK 17 > starting with release 17.0.3. It is not available in JDK 18. > - ... and 13 more: https://git.openjdk.org/jfx/compare/559ad113...842470ae I finished all my testing. This looks good to me, and I have no further questions or concerns. There is some follow-up work that is needed, but that can be done after we get this in. Here are the results of my testing. I did 3 CI builds as well as a few local builds on all three desktop OS platforms. All of my testing was done using the latest compiler devkits and the [kevinrushforth:test-pr-446](/kevinrushforth/jfx/tree/test-pr-446) branch, which is the latest branch from this PR with the latest upstream master merged in. For the first test, I ran without setting `SOURCE_DATE_EPOCH` and compared the results of a build from `test-pr-446` with a build from `master`. All is as expected. For the second test, I compared the results of two builds using the same `SOURCE_DATE_EPOCH` timestamp on the same platform. Except for the native WebKit library on Windows and macOS, everything was identical. For the third test, I compared the results of a local build with the results of a CI build using the same `SOURCE_DATE_EPOCH` timestamp. There were some differences on Windows and Linux in the native binaries that should be followed-up on. #### macOS Two different CI builds on the same system: * Only `libjfxwebkit.dylib` is different Two different builds (CI and local) each on a different macOS 13.x system: * `libjfxwebkit.dylib` is different * `.bss` files differ due to known issue where the absolute file path is recorded in the `.bss` files #### Linux Two different CI builds on the same system: * All artifacts are identical Two different builds (CI and local) each on a different OS platform (Oracle Linux 7.x versus Ubuntu 16.04) with devkit: * All `.so` files are different * `.bss` files differ due to file path issues #### Windows Two different builds on the same system: * Only `jfxwebkit.dll` is different Two different builds (CI and local) each on a different OS platform (Windows 10 versus Windows Server 2016) with devkit: * All `.dll` files are different * `.bss` files differ due to file path issues NOTE: Please merge in the latest master and I'll reapprove. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/446#pullrequestreview-1471918709 From jhendrikx at openjdk.org Fri Jun 9 12:45:02 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Jun 2023 12:45:02 GMT Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with nested nodes (hbox) and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: > This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. > > In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. > > Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. > > The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. > > The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. > > A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. > > Although the test case above was extreme, this change should have positive effects for most applications. John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge branch 'master' of https://git.openjdk.org/jfx into feature/immutable-pseudoclassstate - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() - Merge branch 'master' of https://git.openjdk.org/jfx into feature/immutable-pseudoclassstate - Fix another edge case in BitSet equals When arrays are not the same size, but there are no set bits in the ones the other set doesn't have, two bit sets can still be considered equal - Take element type into account for BitSet.equals() - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray - Removed faulty toArray implementations in PseudoClassState and StyleClassSet - Added test that verifies equals/hashCode for PseudoClassState respect Set contract now - Made getBits package private so it can't be inherited - Remove unused code - Ensure Match doesn't allow modification - Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy - ... and 6 more: https://git.openjdk.org/jfx/compare/9ad0e908...7975ae99 ------------- Changes: https://git.openjdk.org/jfx/pull/1076/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1076&range=07 Stats: 301 lines in 10 files changed: 169 ins; 90 del; 42 mod Patch: https://git.openjdk.org/jfx/pull/1076.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1076/head:pull/1076 PR: https://git.openjdk.org/jfx/pull/1076 From jhendrikx at openjdk.org Fri Jun 9 12:57:51 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Jun 2023 12:57:51 GMT Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with nested nodes (hbox) and pseudo-class in style sheet [v3] In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 05:35:57 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 243: >> >>> 241: public boolean containsAll(Collection c) { >>> 242: if (c == null) { >>> 243: throw new NullPointerException("c cannot be null"); >> >> I wonder if this is necessary - line 246 will produce an NPE with a similar message, right? >> (here and in some other places) > > It would now, if we're okay with implicit null checks. I've switched to implicit null checks, but added a comment saying it is intended. It's also checked in unit tests so no danger of it being changed accidentally. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1224265614 From kcr at openjdk.org Fri Jun 9 13:25:52 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Jun 2023 13:25:52 GMT Subject: RFR: 8309508: Possible memory leak in JPEG image loader In-Reply-To: References: Message-ID: <5ScVIYBgWqI0UuOnETjvirezK71EkgBvG8NX26G7RtM=.476363cd-5c42-4ed0-b63d-cfe54a667417@github.com> On Fri, 9 Jun 2023 05:18:16 GMT, Jayathirth D V wrote: > On code inspection it is revealed that in jpegloader.c->decompressIndirect() we are allocating memory for "scanline_ptr", but if we error_exit() from jpeg_read_scanlines() we are not releasing this memory. > > Added release of "scanline_ptr" with NULL check at appropriate places. > As part of this fix also added RELEASE_ARRAYS() call for stream/pixel buffer in all cases where we move back to Java code. > > Its difficult to create definite pass/fail regression test for memory leak, added noreg-hard label in JBS. Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1151#pullrequestreview-1472058376 From andy.goryachev at oracle.com Fri Jun 9 15:48:58 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 9 Jun 2023 15:48:58 +0000 Subject: [External] : Text Surrounding In-Reply-To: References: Message-ID: Thiago: The IME support is in the plans, so thank you for the info. I am not there yet, but at least I can ask one question regarding the "surrounding" feature: how much text does it expect from the control? Is one line or paragraph enough? Let me ask another question: is the current IME support in TextArea/TextField adequate? Thank you -andy From: Thiago Milczarek Say?o Date: Friday, June 9, 2023 at 03:54 To: Andy Goryachev , openjfx-dev Subject: [External] : Text Surrounding Hi Andy, I understand you're working on a Rich Text control. While working on IME (Input Method Editor) for Linux, I noticed that there is a feature called "surrounding" that it supports to give the IME information about the text being inputted. More info here: https://docs.gtk.org/gtk3/class.IMContext.html It works like this: When user is typing using an IME language, the underlying IME (for example https://github.com/tlwg/ibus-libthai) may ask the Toolkit for the surrounding text and it should reply with: https://docs.gtk.org/gtk3/method.IMContext.set_surrounding.html That contains: - The text - The length - The cursor position within the text So this way the underlying IME can provide accurate suggestions using the user context. That would be a nice feature to have but it requires some work to retrieve it from the text-based control. Just letting you know about this, it may be out of the scope of your rich text work for now. -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Jun 9 15:59:58 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Jun 2023 15:59:58 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v3] In-Reply-To: References: <0LZJQIwWTfmg6C04_iZYqXLg5dlkIm1-PLekNJq4eyI=.f500948f-8f84-48cd-8503-d0b4e716db86@github.com> Message-ID: On Fri, 9 Jun 2023 00:27:05 GMT, Martin Fox wrote: > The portion of this PR that is platform-agnostic was also submitted in PR #1126. will take a look, thanks! ------------- PR Comment: https://git.openjdk.org/jfx/pull/694#issuecomment-1584807626 From duke at openjdk.org Fri Jun 9 18:28:34 2023 From: duke at openjdk.org (Martin Fox) Date: Fri, 9 Jun 2023 18:28:34 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient [v3] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 02:46:47 GMT, Martin Fox wrote: >> Note: the Java-side changes in this PR are also in #694 which fixes the same issue (and more) on Linux. Unfortunately the Linux Robot code is not working making it difficult to test on that platform (see #718). >> >> KeyCharacterCombinations allow the specification of accelerators based on characters whose KeyCodes vary across keyboard layouts. For example, the + character is on KeyCode.EQUALS on a U.S. English layout, KeyCode.PLUS on a German layout, and KeyCode.DIGIT1 on a Mac Swiss German layout. KeyCharacterCombinations finds the correct KeyCode by calling `Toolkit.getKeyCodeForChar`. >> >> `getKeyCodeForChar` can only return one KeyCode for a given character so it can't easily handle characters which appear in more than one location, like + which is on the main keyboard and the numeric keypad. It's also reliant on KeyCodes which prevents KeyCharacterCombinations from working on keys with no codes (e.g. the base character contains a diacritic). It also relies on the platform to map from a character to a key which is the reverse of how key mapping normally works making it slow and/or imprecise to implement on Mac and Linux (Windows is the only platform with a system call to do this). >> >> This PR introduces a new way for a platform to pass key information to the Java core. `View.notifyKeyEx` takes an additional platform-specific `hardwareCode` which identifies the key and is tracked in a private field in the KeyEvent. This is opt-in; a platform can continue to call the old `View.notifyKey` method and allow the `hardwareCode` to default to -1. >> >> On the back-end `KeyCharacterCombination.match` calls the new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the KeyEvent information and sends it on to the Application. This is also opt-in; the default implementation falls back to the Application's `getKeyCodeForChar` call. Platforms which call `View.notifyKeyEx` will be handed the `hardwareCode` for the key in addition to the Java KeyCode. >> >> The new `View.notifyKeyEx` returns a boolean indicating whether the event was consumed or not. This plays no role here but will be used later to fix [JDK-8087863](https://bugs.openjdk.org/browse/JDK-8087863). >> >> For testing I've included the manual KeyboardTest app that also appears in PR #425. Tests with keypad combinations should now work. >> >> Note: this PR only fixes Windows. Fixes for Mac and Linux but can't be submitted until #425 and #718 are integrated. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Renamed notifyKeyEx to notifyKey I added JDK-8274967 as an issue this PR fixes. Support for `Ctrl+'+'` and `Ctrl+'-'` is erratic on Windows without this PR. Currently the platform code finds the correct key but fails to generate the correct Java KeyCode (it uses a hard-coded table that may not correspond to the current layout). With this PR it just compares the platform key code it found to the `hardwareCode` passed in. (BTW, bugs like this are under-represented in the Java bug tracking system. I was looking through the issues list for a JavaFX desktop and saw at least four bugs related to KeyCharacterCombinations spread across all three platforms. App developers have a hard time sorting this out since the behavior varies so much between platforms and layouts and the specific character being targeted.) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1126#issuecomment-1584979525 From angorya at openjdk.org Fri Jun 9 18:44:50 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Jun 2023 18:44:50 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient [v3] In-Reply-To: References: Message-ID: <7iI0ad_HCin9Hqv0ld-k7z4WsQobbByKkxwIwDVemE8=.fa8673cb-27fb-4d88-818f-28fb511b40ed@github.com> On Fri, 9 Jun 2023 18:25:39 GMT, Martin Fox wrote: > App developers have a hard time sorting this out There was a discussion on the mailing list about adding a doc/ folder with markdown informational notes. (Build instructions and snapping rules were the prime candidates for such notes). If you could write such an explanatory note, we could put it there (there is no JBS issue for the doc/ folder, I'll create one). Another suggestion is that we could create an umbrella task linking all related issues, as we did, for example with skin changing [JDK-8241364](https://bugs.openjdk.org/browse/JDK-8241364). What do you think? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1126#issuecomment-1584996182 From duke at openjdk.org Fri Jun 9 20:04:03 2023 From: duke at openjdk.org (Martin Fox) Date: Fri, 9 Jun 2023 20:04:03 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient [v3] In-Reply-To: References: Message-ID: <0xydKzXQ152Oz6L3x3FrmTOXbfRUw_2cyFd3Xj4Wopw=.fcbbac19-fc8b-4b38-9316-093af5e5de1d@github.com> On Thu, 11 May 2023 02:46:47 GMT, Martin Fox wrote: >> Note: the Java-side changes in this PR are also in #694 which fixes the same issue (and more) on Linux. Unfortunately the Linux Robot code is not working making it difficult to test on that platform (see #718). >> >> KeyCharacterCombinations allow the specification of accelerators based on characters whose KeyCodes vary across keyboard layouts. For example, the + character is on KeyCode.EQUALS on a U.S. English layout, KeyCode.PLUS on a German layout, and KeyCode.DIGIT1 on a Mac Swiss German layout. KeyCharacterCombinations finds the correct KeyCode by calling `Toolkit.getKeyCodeForChar`. >> >> `getKeyCodeForChar` can only return one KeyCode for a given character so it can't easily handle characters which appear in more than one location, like + which is on the main keyboard and the numeric keypad. It's also reliant on KeyCodes which prevents KeyCharacterCombinations from working on keys with no codes (e.g. the base character contains a diacritic). It also relies on the platform to map from a character to a key which is the reverse of how key mapping normally works making it slow and/or imprecise to implement on Mac and Linux (Windows is the only platform with a system call to do this). >> >> This PR introduces a new way for a platform to pass key information to the Java core. `View.notifyKeyEx` takes an additional platform-specific `hardwareCode` which identifies the key and is tracked in a private field in the KeyEvent. This is opt-in; a platform can continue to call the old `View.notifyKey` method and allow the `hardwareCode` to default to -1. >> >> On the back-end `KeyCharacterCombination.match` calls the new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the KeyEvent information and sends it on to the Application. This is also opt-in; the default implementation falls back to the Application's `getKeyCodeForChar` call. Platforms which call `View.notifyKeyEx` will be handed the `hardwareCode` for the key in addition to the Java KeyCode. >> >> The new `View.notifyKeyEx` returns a boolean indicating whether the event was consumed or not. This plays no role here but will be used later to fix [JDK-8087863](https://bugs.openjdk.org/browse/JDK-8087863). >> >> For testing I've included the manual KeyboardTest app that also appears in PR #425. Tests with keypad combinations should now work. >> >> Note: this PR only fixes Windows. Fixes for Mac and Linux but can't be submitted until #425 and #718 are integrated. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Renamed notifyKeyEx to notifyKey In the mailing list discussion the doc/ folder was intended for internal JavaFX developers and not for users of JavaFX. I was planning on updating the public JavaDocs but that means spreading the information out across the KeyCode, KeyCombination, KeyCharacterCombination, and KeyCodeCombination classes. A short overview document would be nice to have but would that be suitable for the proposed doc/ folder? I think what most developers need is a) for us to fix our bugs and b) to know that KeyCharacterCombinations should be used for accelerators involving symbols and punctuation and KeyCodeCombinations should be used for everything else. I should probably add that to the KeyCombination documentation sooner rather than later. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1126#issuecomment-1585067801 From duke at openjdk.org Fri Jun 9 23:14:04 2023 From: duke at openjdk.org (Martin Fox) Date: Fri, 9 Jun 2023 23:14:04 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v5] In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 00:22:57 GMT, Thiago Milczarek Sayao wrote: >> Martin Fox has updated the pull request incrementally with one additional commit since the last revision: >> >> Updating classpath for Eclipse users > > tests/manual/events/KeyCharacterCombinationTest.java line 45: > >> 43: >> 44: @Override >> 45: public void start(Stage stage) { > > I started the test app but was unsure how to test it. Maybe add a header text that explains how a successful test should go. There's now a better test app in tests/manual/events/KeyboardTest.java. With KeyCharacterCombinationTest the human tester has to press a bunch of keys. KeyboardTest.java uses a Robot to automate the process. The downside is that KeyboardTest.java relies on working Robot code so it can't really be used on Linux until #718 is integrated. I'll update the comments on this in the interim. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/694#discussion_r1224807391 From angorya at openjdk.org Fri Jun 9 23:14:03 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Jun 2023 23:14:03 GMT Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with nested nodes (hbox) and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 12:45:02 GMT, John Hendrikx wrote: >> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. >> >> In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. >> >> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. >> >> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. >> >> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. >> >> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. >> >> Although the test case above was extreme, this change should have positive effects for most applications. > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate > - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Fix another edge case in BitSet equals > > When arrays are not the same size, but there are no set bits in the ones > the other set doesn't have, two bit sets can still be considered equal > - Take element type into account for BitSet.equals() > - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray > > - Removed faulty toArray implementations in PseudoClassState and > StyleClassSet > - Added test that verifies equals/hashCode for PseudoClassState respect > Set contract now > - Made getBits package private so it can't be inherited > - Remove unused code > - Ensure Match doesn't allow modification > - Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy > - ... and 6 more: https://git.openjdk.org/jfx/compare/9ad0e908...7975ae99 one question: since the JBS talks about memory leak, is it possible to devise a test for that? otherwise, looks good. ------------- PR Review: https://git.openjdk.org/jfx/pull/1076#pullrequestreview-1400397240 From angorya at openjdk.org Fri Jun 9 23:14:04 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Jun 2023 23:14:04 GMT Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with nested nodes (hbox) and pseudo-class in style sheet [v6] In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 07:14:07 GMT, John Hendrikx wrote: >> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. >> >> In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. >> >> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. >> >> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. >> >> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. >> >> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. >> >> Although the test case above was extreme, this change should have positive effects for most applications. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Avoid using Lambda in ImmutablePseudoClassSetsCache.of() modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 44: > 42: * which makes matching faster. > 43: */ > 44: abstract class BitSet extends AbstractSet implements ObservableSet { Since this is an internal class, would it be possible / make sense to rename it, to avoid confusion with the real Slim^H^H^H^H BitSet? StyleBitSetBase or some such? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1176824497 From angorya at openjdk.org Fri Jun 9 23:14:04 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Jun 2023 23:14:04 GMT Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with nested nodes (hbox) and pseudo-class in style sheet [v6] In-Reply-To: References: Message-ID: <9gdYvSE41vWTRcdnB1iZ8x6g1WSGK2jey0wiQhnTwRU=.a95fc768-20aa-470a-9a77-d40a89f31bbd@github.com> On Tue, 25 Apr 2023 17:26:54 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid using Lambda in ImmutablePseudoClassSetsCache.of() > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 44: > >> 42: * which makes matching faster. >> 43: */ >> 44: abstract class BitSet extends AbstractSet implements ObservableSet { > > Since this is an internal class, would it be possible / make sense to rename it, to avoid confusion with the real Slim^H^H^H^H BitSet? StyleBitSetBase or some such? BitSet name still bugs me. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1224829679 From kcr at openjdk.org Fri Jun 9 23:44:51 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Jun 2023 23:44:51 GMT Subject: RFR: 8306021: Add event handler management to EventTarget [v4] In-Reply-To: References: <5BIM8D2acRWXNCALew4jS8OrndcHWMWC9-hCDCkvLwI=.f1283fbc-0421-48d1-b81d-b979437d1770@github.com> Message-ID: On Mon, 17 Apr 2023 06:00:19 GMT, Michael Strau? wrote: >> This PR adds the following methods to the `EventTarget` interface: >> 1. `addEventHandler` >> 2. `removeEventHandler` >> 3. `addEventFilter` >> 4. `removeEventFilter` > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > doc changes The spec looks fine except for a few missing `@since` tags that need to be restored, a suggestion on adding `@implSpec` (from Joe), and a couple unrelated doc changes that should be reverted. See inline. As for the implementation, the event handling methods in the `Dialog` and `Tab` classes are new (although they just delegate to an existing instance of `EventHandlerManager`). Would it be possible to provide a test? modules/javafx.base/src/main/java/javafx/event/EventTarget.java line 68: > 66: * @param eventHandler the event handler > 67: * @throws NullPointerException if {@code eventType} or {@code eventHandler} is {@code null} > 68: * @throws UnsupportedOperationException if this target does not support event handlers Joe Darcy made a recommendation while reviewing the CSR to add an `@implSpec` tag to the 4 added default methods documenting their behavior, which I think is a good suggestion. Here is a possible wording: @implSpec The default implementation of this method throws {@code UnsupportedOperationException}. modules/javafx.controls/src/main/java/javafx/scene/control/TableColumn.java line 85: > 83: *
  • {@link #editCancelEvent()} > 84: * > 85: * These doc additions are unrelated to the this PR. modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableColumn.java line 80: > 78: *
  • {@link #editCancelEvent()} > 79: * > 80: * These doc additions are unrelated to the this PR. modules/javafx.graphics/src/main/java/javafx/concurrent/Service.java line 744: > 742: } > 743: > 744: @Override By removing the docs, you lost the `@since` for this method, so you will need to restore it. You might consider also adding `{@inheritDoc}` to avoid copying all of the description modules/javafx.graphics/src/main/java/javafx/concurrent/Task.java line 1252: > 1250: > 1251: @Override > 1252: public final void addEventHandler( Same comment in this file about the need to restore the `@since tag`. modules/javafx.graphics/src/main/java/javafx/scene/transform/Transform.java line 1915: > 1913: *

    > 1914: * Currently the only event delivered to a {@code Transform} is the {@code TransformChangedEvent} > 1915: * with its single type {@code TRANSFORM_CHANGED}. You need to restore the `@since` ------------- Changes requested by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1090#pullrequestreview-1472963662 PR Review Comment: https://git.openjdk.org/jfx/pull/1090#discussion_r1224696281 PR Review Comment: https://git.openjdk.org/jfx/pull/1090#discussion_r1224894283 PR Review Comment: https://git.openjdk.org/jfx/pull/1090#discussion_r1224894379 PR Review Comment: https://git.openjdk.org/jfx/pull/1090#discussion_r1224877090 PR Review Comment: https://git.openjdk.org/jfx/pull/1090#discussion_r1224877506 PR Review Comment: https://git.openjdk.org/jfx/pull/1090#discussion_r1224881183 From jhendrikx at openjdk.org Sat Jun 10 00:10:52 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Jun 2023 00:10:52 GMT Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with nested nodes (hbox) and pseudo-class in style sheet [v6] In-Reply-To: <9gdYvSE41vWTRcdnB1iZ8x6g1WSGK2jey0wiQhnTwRU=.a95fc768-20aa-470a-9a77-d40a89f31bbd@github.com> References: <9gdYvSE41vWTRcdnB1iZ8x6g1WSGK2jey0wiQhnTwRU=.a95fc768-20aa-470a-9a77-d40a89f31bbd@github.com> Message-ID: On Fri, 9 Jun 2023 22:11:10 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 44: >> >>> 42: * which makes matching faster. >>> 43: */ >>> 44: abstract class BitSet extends AbstractSet implements ObservableSet { >> >> Since this is an internal class, would it be possible / make sense to rename it, to avoid confusion with the real Slim^H^H^H^H BitSet? StyleBitSetBase or some such? > > BitSet name still bugs me. Sure, but I think that would be out of scope for this PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1224906677 From jhendrikx at openjdk.org Sat Jun 10 00:23:51 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Jun 2023 00:23:51 GMT Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with nested nodes (hbox) and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 22:08:53 GMT, Andy Goryachev wrote: > one question: since the JBS talks about memory leak, is it possible to devise a test for that? > > otherwise, looks good. It's not really a memory leak, the amount of memory that it can take can just be quite large in the right circumstances. Once it has been allocated though, it will remain the same and won't grow further. The test in `ImmutablePseudoClassSetsCacheTest` confirms (at a unit level) that it is indeed caching sets that are the same. It may be possible to create a higher level test as well, similar to the code example in the ticket. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1076#issuecomment-1585302657 From duke at openjdk.org Sat Jun 10 02:28:53 2023 From: duke at openjdk.org (duke) Date: Sat, 10 Jun 2023 02:28:53 GMT Subject: Withdrawn: 8268642: Improve property system to facilitate correct usage In-Reply-To: <6wNqOyLEuepHxTUhZ7WNSrv37hXf_zVctzAhbZphBKA=.a1a5b5ef-9c51-464b-9621-952d316024b0@github.com> References: <6wNqOyLEuepHxTUhZ7WNSrv37hXf_zVctzAhbZphBKA=.a1a5b5ef-9c51-464b-9621-952d316024b0@github.com> Message-ID: On Tue, 27 Jul 2021 23:15:10 GMT, Michael Strau? wrote: > Based on previous discussions, this PR attempts to improve the JavaFX property system by enforcing correct API usage in several cases that are outlined below. It also streamlines the API by deprecating untyped APIs in favor of typed APIs that better express intent. > > ### 1. Behavioral changes for regular bindings > > var target = new SimpleObjectProperty(bean, "target"); > var source = new SimpleObjectProperty(bean, "source"); > target.bind(source); > target.bindBidirectional(source); > > _Before:_ `RuntimeException` --> "bean.target: A bound value cannot be set." > _After:_ `IllegalStateException` --> "bean.target: Bidirectional binding cannot target a bound property." > > > var target = new SimpleObjectProperty(bean, "target"); > var source = new SimpleObjectProperty(bean, "source"); > var other = new SimpleObjectProperty(bean, "other"); > source.bind(other); > target.bindBidirectional(source); > > _Before:_ no error > _After:_ `IllegalArgumentException` --> "bean.source: Bidirectional binding cannot target a bound property." > > > var target = new SimpleObjectProperty(bean, "target"); > var source = new SimpleObjectProperty(bean, "source"); > target.bindBidirectional(source); > target.bind(source); > > _Before:_ no error > _After:_ `IllegalStateException` --> "bean.target: Cannot bind a property that is targeted by a bidirectional binding." > > > ### 2. Behavioral changes for content bindings > > var target = new SimpleListProperty(bean, "target"); > var source = new SimpleListProperty(bean, "source"); > target.bindContent(source); > target.bindContentBidirectional(source); > > _Before:_ no error > _After:_ `IllegalStateException` --> "bean.target: Bidirectional content binding cannot target a bound collection." > > > var target = new SimpleListProperty(bean, "target"); > var source = new SimpleListProperty(bean, "source"); > var other = new SimpleListProperty(); > source.bindContent(other); > target.bindContentBidirectional(source); > > _Before:_ no error > _After:_ `IllegalArgumentException` --> "bean.source: Bidirectional content binding cannot target a bound collection." > > > var target = new SimpleListProperty(bean, "target"); > var source = new SimpleListProperty(bean, "source"); > target.bindContentBidirectional(source); > target.bindContent(source); > > _Before:_ no error > _After:_ `IllegalStateException` --> "bean.target: Cannot bind a collection that is targeted by a bidirectional content binding." > > > var target = new SimpleListProperty(bean, "target"); > var source = new SimpleListProperty(bean, "source"); > target.bindContent(source); > targ... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/590 From duke at openjdk.org Sat Jun 10 02:34:03 2023 From: duke at openjdk.org (duke) Date: Sat, 10 Jun 2023 02:34:03 GMT Subject: Withdrawn: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: Message-ID: On Thu, 6 Feb 2020 16:13:33 GMT, dannygonzalez wrote: > https://bugs.openjdk.java.net/browse/JDK-8185886 > > Optimisation to ExpressionHelper.Generic class to use Sets rather than Arrays to improve listener removal speed. > > This was due to the removal of listeners in TableView taking up to 50% of CPU time on the JavaFX Application thread when scrolling/adding rows to TableViews. > > This may alleviate some of the issues seen here: > > TableView has a horrific performance with many columns #409 > https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033 > > JDK-8088394 : Huge memory consumption in TableView with too many columns > JDK-8166956: JavaFX TreeTableView slow scroll performance > JDK-8185887: TableRowSkinBase fails to correctly virtualise cells in horizontal direction > > OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns > https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/108 From kcr at openjdk.org Sat Jun 10 13:31:46 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Jun 2023 13:31:46 GMT Subject: RFR: 8306648: Update the JavaDocs to show the NEW section and DEPRECATED versions [v2] In-Reply-To: <_ZIjWqwdk6y5m6VDatnq_aVme3nUtFqb_OAJixTS4Ys=.59fb079b-5dfe-423c-ba0c-586fc1ec47c9@github.com> References: <_ZIjWqwdk6y5m6VDatnq_aVme3nUtFqb_OAJixTS4Ys=.59fb079b-5dfe-423c-ba0c-586fc1ec47c9@github.com> Message-ID: On Thu, 8 Jun 2023 21:53:35 GMT, Marius Hanl wrote: > > I am somewhat divided on which version to start with. On one hand, it makes sense to use last LTS version (or previous, if the current one is also LTS), so 17. > > I think we should either start from 9 or 11. Depending on the source, Java 11 is used more often than 8, which probably also means JavaFX 11+ is used more often than 8. I tend to agree that we should either start with 9 or 11. I can also see an argument for starting with 12 like the JDK did, but I am not in favor of that, given that this is the first time we are introducing the NEW section. If we think that most new readers of these docs will be coming from JDK 8, then **NEW since 9** makes the most sense. Worth noting, though, is that FX was bundled with the JDK in 8 and 9 (and 10) -- JavaFX 11 was the first unbundled release, which would argue for **NEW since 11**. Another argument for starting with 9 is that the reader who is just interested in what's new since 11 can simply uncheck 9 and 10 and get that view. So if there is some value in presenting new in 9, that argues for starting with 9. Unless someone feels strongly that we shouldn't, let's stick with 9. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1109#issuecomment-1585666839 From thiago.sayao at gmail.com Sat Jun 10 14:05:49 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Sat, 10 Jun 2023 11:05:49 -0300 Subject: [External] : Text Surrounding In-Reply-To: References: Message-ID: Andy, Looking at Gtk code on: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtktextview.c -> gtk_text_view_retrieve_surrounding_handler It seems to concat 3 words backwards + selection + 3 words forward (there are more complicated cases). I was looking around on JavaFX code and it does not seem to support this feature (surrounding). I don't know if Windows and/or Mac supports it. If implemented it should work for all text input controls. Gtk seems to have been adopting relative window positioning for everything as opposed to Screen positioning and InputMethodRequests.getTextLocation is absolute. Would be nice to have the relative value. -- Thiago Em sex., 9 de jun. de 2023 ?s 12:49, Andy Goryachev < andy.goryachev at oracle.com> escreveu: > Thiago: > > > > The IME support is in the plans, so thank you for the info. I am not > there yet, but at least I can ask one question regarding the "surrounding" > feature: how much text does it expect from the control? Is one line or > paragraph enough? > > > > Let me ask another question: is the current IME support in > TextArea/TextField adequate? > > > > Thank you > > -andy > > > > > > > > > > *From: *Thiago Milczarek Say?o > *Date: *Friday, June 9, 2023 at 03:54 > *To: *Andy Goryachev , openjfx-dev < > openjfx-dev at openjdk.org> > *Subject: *[External] : Text Surrounding > > Hi Andy, > > > > I understand you're working on a Rich Text control. > > > > While working on IME (Input Method Editor) for Linux, I noticed that there > is a feature called "surrounding" > > that it supports to give the IME information about the text being > inputted. More info here: > > > > https://docs.gtk.org/gtk3/class.IMContext.html > > > > > It works like this: > > > > When user is typing using an IME language, the underlying IME (for example > https://github.com/tlwg/ibus-libthai > > ) > > may ask the Toolkit for the surrounding text and it should reply with: > > > > https://docs.gtk.org/gtk3/method.IMContext.set_surrounding.html > > > > > That contains: > > - The text > > - The length > > - The cursor position within the text > > > > So this way the underlying IME can provide accurate suggestions using the > user context. > > > > That would be a nice feature to have but it requires some work to retrieve > it from the text-based control. > > > > Just letting you know about this, it may be out of the scope of your rich > text work for now. > > > > -- Thiago. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Sat Jun 10 14:12:48 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Jun 2023 14:12:48 GMT Subject: RFR: 8306648: Update the JavaDocs to show the NEW section and DEPRECATED versions [v2] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 11:39:24 GMT, Nir Lisker wrote: >> Adds the javadoc commands to generate the NEW page and to be able to select versions in the DEPRECATED page. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Auto-detect latest version Marked as reviewed by kcr (Lead). > > The `-since` option does not play well with the javafx one: if documentation was added on a `private` property field with the `@since` tag, it will not be included in the NEW and DEPRECATED lists. > > Confirmed. I can file a bug against the javadoc tool. This looks like one more place where they need to handle JavaFX properties. I filed [JDK-8309765](https://bugs.openjdk.org/browse/JDK-8309765) to track this. ------------- PR Review: https://git.openjdk.org/jfx/pull/1109#pullrequestreview-1473427741 PR Comment: https://git.openjdk.org/jfx/pull/1109#issuecomment-1585679728 From kcr at openjdk.org Sat Jun 10 14:29:55 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Jun 2023 14:29:55 GMT Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with nested nodes (hbox) and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Sat, 10 Jun 2023 00:20:43 GMT, John Hendrikx wrote: > It's not really a memory leak, the amount of memory that it can take can just be quite large in the right circumstances. In that case, I edited the title of the JBS bug to remove the `Memory leak and` part (I also remove the `(hbox)` since any nested container could do the same). Can you edit the PR title to match? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1076#issuecomment-1585686953 From tsayao at openjdk.org Sat Jun 10 19:15:56 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 10 Jun 2023 19:15:56 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v20] In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 01:09:36 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Insert copyright I confirm that even restoring [JDK-8296621](https://bugs.openjdk.org/browse/JDK-8296621), the tests were not getting focus. I did this by adding to `MouseEventFirerTest` on `setup`: topLeft.focusedProperty().addListener((observable, oldValue, newValue) -> { System.out.println("topLeft focused " + newValue); }); stage.focusedProperty().addListener((observable, oldValue, newValue) -> { System.out.println("Stage focused " + newValue); }); And adding `testLogging.showStandardStreams = true;` to `build.gradle` With this PR, focus messages are shown, without the PR or restoring [JDK-8296621](https://bugs.openjdk.org/browse/JDK-8296621) they don't. Probably something to do with Monocle flow. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1585775877 From tsayao at openjdk.org Sat Jun 10 19:59:54 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 10 Jun 2023 19:59:54 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v18] In-Reply-To: <18C90tKvwVgTrWuQ3TFhuovrhNa6xKx8hYoXy5kPc50=.4f2cd1c2-dc71-41af-a20a-4223950e4d0b@github.com> References: <90Qbdi_mFQbCH7sn5q1Jf_wJbWa9HK_QWDWyRoRAeGk=.350ee310-1ad4-4cd8-bb0f-67e5cf0084a1@github.com> <18C90tKvwVgTrWuQ3TFhuovrhNa6xKx8hYoXy5kPc50=.4f2cd1c2-dc71-41af-a20a-4223950e4d0b@github.com> Message-ID: On Tue, 6 Jun 2023 14:03:35 GMT, Kevin Rushforth wrote: >>> I ran an automated test job using your latest patch and all of the tests now pass. >>> >>> > Maybe it's possible to do a Java fix where the new Scene without size inherits the old Scene size? This way I think it possible to remove platform specific code such as the one I did and `_updateViewSize`. >>> >>> Hmm. That might be problematic. In any case, I don't want to go down that route to fix this bug. >>> >>> I have two questions on the current version of the fix: >>> >>> 1. Can you explain why the two tests had to be changed? Unless the tests in question really were buggy, and just getting luck before, the changes suggest a change in behavior that applications might notice and be bothered by. >>> >>> 2. Are you sure that on Linux, there are no cases where `_updateViewSize` needs to be implemented? Did you consider just leaving it as-is or would that have failed? >> >> I changed it to use `_updateViewSize` so it's compatible with other platforms. >> >> I'm gathering some information to answer about the test changes. > >> I changed it to use `_updateViewSize` so it's compatible with other platforms. > > As it turns out, I was looking at your incremental diff and (mistakenly) thought that `_updateViewSize` was in the current mainline code base and that you had removed it, which is why I asked about it. I now see that what happened is that the initial version of your PR had added it, and a later version had reverted that addition. And your most recent version added it back in. I don't mind either way, so if you think it's cleaner to implement `_updateViewSize` on Linux (even though today it's only implemented on Windows), that's OK. If you want to revert this latest addition of that method, that's OK, too. > >> I'm gathering some information to answer about the test changes. > > Thanks. @kevinrushforth Got it. Testing uses `StubToolkit` and not `QuantumToolkit` which before [JDK-8296621](https://bugs.openjdk.org/browse/JDK-8296621) called `requestFocus()` inside `WindowStage` which is part of `QuantumToolkit`. So focusing were never taken into account while testing. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1585792601 From duke at openjdk.org Sun Jun 11 06:14:54 2023 From: duke at openjdk.org (duke) Date: Sun, 11 Jun 2023 06:14:54 GMT Subject: Withdrawn: 8305768: Unify WindowContext in glass-gtk In-Reply-To: References: Message-ID: On Sat, 8 Apr 2023 00:53:12 GMT, Thiago Milczarek Sayao wrote: > This unifies and organizes WindowContext of the glass-gtk. > > It does not change any behaviour, just reorganizes the code. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1085 From thiago.sayao at gmail.com Sun Jun 11 13:26:22 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Sun, 11 Jun 2023 10:26:22 -0300 Subject: [External] : Text Surrounding In-Reply-To: References: Message-ID: Andy, I noticed another missing feature. The OS IME may also set text attributes such as font and color. When reporting the IME back to JavaFX it should support setting text attributes. It looks like it was planned, but not yet implemented. I think it would go in InputMethodTextRun.java, that is set by GlassViewEventHandler.java. On linux it comes from: https://docs.gtk.org/gtk3/method.IMContext.get_preedit_string.html This function returns the pango attributes that should be reported back to javafx. That would go nicely on a rich text control. It also looks the IME event could be more explicit: inputMethodEventComposed( String text, int commitCount, int[] clauseBoundary, int[] attrBoundary, byte[] attrValue) Those arrays are very confusing. -- Thiago Em sex., 9 de jun. de 2023 ?s 12:49, Andy Goryachev < andy.goryachev at oracle.com> escreveu: > Thiago: > > > > The IME support is in the plans, so thank you for the info. I am not > there yet, but at least I can ask one question regarding the "surrounding" > feature: how much text does it expect from the control? Is one line or > paragraph enough? > > > > Let me ask another question: is the current IME support in > TextArea/TextField adequate? > > > > Thank you > > -andy > > > > > > > > > > *From: *Thiago Milczarek Say?o > *Date: *Friday, June 9, 2023 at 03:54 > *To: *Andy Goryachev , openjfx-dev < > openjfx-dev at openjdk.org> > *Subject: *[External] : Text Surrounding > > Hi Andy, > > > > I understand you're working on a Rich Text control. > > > > While working on IME (Input Method Editor) for Linux, I noticed that there > is a feature called "surrounding" > > that it supports to give the IME information about the text being > inputted. More info here: > > > > https://docs.gtk.org/gtk3/class.IMContext.html > > > > > It works like this: > > > > When user is typing using an IME language, the underlying IME (for example > https://github.com/tlwg/ibus-libthai > > ) > > may ask the Toolkit for the surrounding text and it should reply with: > > > > https://docs.gtk.org/gtk3/method.IMContext.set_surrounding.html > > > > > That contains: > > - The text > > - The length > > - The cursor position within the text > > > > So this way the underlying IME can provide accurate suggestions using the > user context. > > > > That would be a nice feature to have but it requires some work to retrieve > it from the text-based control. > > > > Just letting you know about this, it may be out of the scope of your rich > text work for now. > > > > -- Thiago. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kpk at openjdk.org Mon Jun 12 05:42:47 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 12 Jun 2023 05:42:47 GMT Subject: RFR: 8304922: [testbug] SliderTooltipNPETest fails on Linux [v2] In-Reply-To: References: Message-ID: <3yoMKZ0zkCisfP94SBPT6upsDDUGMafhA9FEGe8PLl4=.afa5c813-6bd4-44a9-b6b9-d64911444b6d@github.com> On Fri, 28 Apr 2023 14:24:16 GMT, Kevin Rushforth wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Add latch for tooltip hide and mouse move events > > It doesn't work for me. @kevinrushforth could you please check the updated fix whenever possible? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1119#issuecomment-1586616871 From arapte at openjdk.org Mon Jun 12 14:43:50 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 12 Jun 2023 14:43:50 GMT Subject: RFR: 8309508: Possible memory leak in JPEG image loader In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 05:18:16 GMT, Jayathirth D V wrote: > On code inspection it is revealed that in jpegloader.c->decompressIndirect() we are allocating memory for "scanline_ptr", but if we error_exit() from jpeg_read_scanlines() we are not releasing this memory. > > Added release of "scanline_ptr" with NULL check at appropriate places. > As part of this fix also added RELEASE_ARRAYS() call for stream/pixel buffer in all cases where we move back to Java code. > > Its difficult to create definite pass/fail regression test for memory leak, added noreg-hard label in JBS. lgtm. ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1151#pullrequestreview-1475110351 From angorya at openjdk.org Mon Jun 12 15:01:55 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Jun 2023 15:01:55 GMT Subject: RFR: 8306648: Update the JavaDocs to show the NEW section and DEPRECATED versions [v2] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 11:39:24 GMT, Nir Lisker wrote: >> Adds the javadoc commands to generate the NEW page and to be able to select versions in the DEPRECATED page. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Auto-detect latest version thank you for explanations - since 9 is fine. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1109#pullrequestreview-1475151431 From nlisker at openjdk.org Mon Jun 12 15:15:54 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 12 Jun 2023 15:15:54 GMT Subject: Integrated: 8306648: Update the JavaDocs to show the NEW section and DEPRECATED versions In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 13:18:31 GMT, Nir Lisker wrote: > Adds the javadoc commands to generate the NEW page and to be able to select versions in the DEPRECATED page. This pull request has now been integrated. Changeset: 9913b23a Author: Nir Lisker URL: https://git.openjdk.org/jfx/commit/9913b23a5b9d4cbe27e40cf58d425fbb00cec6e6 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8306648: Update the JavaDocs to show the NEW section and DEPRECATED versions Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1109 From jdv at openjdk.org Mon Jun 12 16:01:51 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 12 Jun 2023 16:01:51 GMT Subject: Integrated: 8309508: Possible memory leak in JPEG image loader In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 05:18:16 GMT, Jayathirth D V wrote: > On code inspection it is revealed that in jpegloader.c->decompressIndirect() we are allocating memory for "scanline_ptr", but if we error_exit() from jpeg_read_scanlines() we are not releasing this memory. > > Added release of "scanline_ptr" with NULL check at appropriate places. > As part of this fix also added RELEASE_ARRAYS() call for stream/pixel buffer in all cases where we move back to Java code. > > Its difficult to create definite pass/fail regression test for memory leak, added noreg-hard label in JBS. This pull request has now been integrated. Changeset: bd24fc72 Author: Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/bd24fc7286725358f109863e6cc8a6c3abb354e1 Stats: 14 lines in 1 file changed: 9 ins; 0 del; 5 mod 8309508: Possible memory leak in JPEG image loader Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1151 From mstrauss at openjdk.org Mon Jun 12 18:17:17 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 12 Jun 2023 18:17:17 GMT Subject: RFR: 8306021: Add event handler management to EventTarget [v5] In-Reply-To: <5BIM8D2acRWXNCALew4jS8OrndcHWMWC9-hCDCkvLwI=.f1283fbc-0421-48d1-b81d-b979437d1770@github.com> References: <5BIM8D2acRWXNCALew4jS8OrndcHWMWC9-hCDCkvLwI=.f1283fbc-0421-48d1-b81d-b979437d1770@github.com> Message-ID: > This PR adds the following methods to the `EventTarget` interface: > 1. `addEventHandler` > 2. `removeEventHandler` > 3. `addEventFilter` > 4. `removeEventFilter` Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - added tests - Code review changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1090/files - new: https://git.openjdk.org/jfx/pull/1090/files/2557fb2f..f2236946 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1090&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1090&range=03-04 Stats: 147 lines in 8 files changed: 119 ins; 20 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1090.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1090/head:pull/1090 PR: https://git.openjdk.org/jfx/pull/1090 From duke at openjdk.org Mon Jun 12 20:03:52 2023 From: duke at openjdk.org (duke) Date: Mon, 12 Jun 2023 20:03:52 GMT Subject: Withdrawn: JDK-8304323 Provide infrastructure to make it possible for properties to delay listener registration In-Reply-To: References: Message-ID: On Sun, 5 Feb 2023 13:07:25 GMT, John Hendrikx wrote: > This PR contains changes to make it easier to implement properties which want to conserve resources until they're observed themselves. > > `isObserved` is promoted from `ObjectBinding` to the `ObservableValue` interface, allowing you to ask any `ObservableValue` if it is currently observed (ie. if it has any listeners registered on it). All JavaFX `ObservableValue`s implementations are modified to implement this method. > > The protected methods `observed` and `unobserved` are added to all extendable (non final) `ObservableValue`s provided by JavaFX. The `observed` call back is only called when the observable currently has 0 listeners and will soon have 1 listener. During the call back, `isObserved` still returns `false` (see below for why this was chosen). The `unobserved` call back is only called when the last listener was removed and the observable has 0 listeners. During the call back, `isObserved` will already return `false`. > > The reason why `observed` is called before `isObserved` starts returning `true` (and also why `unobserved` works the opposite) is to make it easy to implement a parent-child relationship where a nested property becoming observed may need to trigger behavior in its parent. Given a parent class and two nested properties `foo` and `bar`: > > class FooProperty extends ObjectPropertyBase { > void observed() { > nestedPropertyObserved(); // call to parent > } > > void unobserved() { > nestedPropertyUnobserved(); // call to parent > } > } > > The parent may determine whether any of the properties is observed with a helper: > > private boolean isANestedPropertyObserved() { > return foo.isObserved() || bar.isObserved(); > } > > The `nestedPropertyObserved` and `nestedPropertyUnobserved` methods can now be implemented simply as: > > private void nestedPropertyObserved() { > if (!isANestedPropertyObserved()) { > // take action as no properties were observed before, but now one will become observed > } > } > > private void nestedPropertyUnobserved() { > if (!isANestedPropertyObserved()) { > // take action as a property was observed before, but the last listener is about to be removed > } > } > > If `isObserved` would change immediately, this becomes more difficult as the observed status of the property that has just become observed would need to be excluded to determine if this is the... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1023 From nlisker at openjdk.org Mon Jun 12 20:16:52 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 12 Jun 2023 20:16:52 GMT Subject: RFR: 8306021: Add event handler management to EventTarget [v5] In-Reply-To: References: <5BIM8D2acRWXNCALew4jS8OrndcHWMWC9-hCDCkvLwI=.f1283fbc-0421-48d1-b81d-b979437d1770@github.com> Message-ID: <6DR-aip6Hka5phskz5ORcDb7BT_3O3eCe_rgPJwqJfw=.a7b86193-3a17-48bd-b4d1-c1022ab5bb76@github.com> On Mon, 12 Jun 2023 18:17:17 GMT, Michael Strau? wrote: >> This PR adds the following methods to the `EventTarget` interface: >> 1. `addEventHandler` >> 2. `removeEventHandler` >> 3. `addEventFilter` >> 4. `removeEventFilter` > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - added tests > - Code review changes Marked as reviewed by nlisker (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1090#pullrequestreview-1475735325 From angorya at openjdk.org Mon Jun 12 20:16:53 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Jun 2023 20:16:53 GMT Subject: RFR: 8306021: Add event handler management to EventTarget [v5] In-Reply-To: References: <5BIM8D2acRWXNCALew4jS8OrndcHWMWC9-hCDCkvLwI=.f1283fbc-0421-48d1-b81d-b979437d1770@github.com> Message-ID: On Mon, 12 Jun 2023 18:17:17 GMT, Michael Strau? wrote: >> This PR adds the following methods to the `EventTarget` interface: >> 1. `addEventHandler` >> 2. `removeEventHandler` >> 3. `addEventFilter` >> 4. `removeEventFilter` > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - added tests > - Code review changes Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1090#pullrequestreview-1475738478 From mhanl at openjdk.org Mon Jun 12 20:24:55 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 12 Jun 2023 20:24:55 GMT Subject: RFR: 8306021: Add event handler management to EventTarget [v5] In-Reply-To: References: <5BIM8D2acRWXNCALew4jS8OrndcHWMWC9-hCDCkvLwI=.f1283fbc-0421-48d1-b81d-b979437d1770@github.com> Message-ID: On Mon, 12 Jun 2023 18:17:17 GMT, Michael Strau? wrote: >> This PR adds the following methods to the `EventTarget` interface: >> 1. `addEventHandler` >> 2. `removeEventHandler` >> 3. `addEventFilter` >> 4. `removeEventFilter` > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - added tests > - Code review changes Marked as reviewed by mhanl (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1090#pullrequestreview-1475754096 From kcr at openjdk.org Mon Jun 12 21:38:47 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Jun 2023 21:38:47 GMT Subject: RFR: 8304922: [testbug] SliderTooltipNPETest fails on Linux [v2] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 12:00:59 GMT, Karthik P K wrote: >> The test was failing on the first run and then it was not failing. Cause for the failure looked to be the UI state not getting updated. Hence added call to `Toolkit` `firePulse` method. >> >> Able to run the test consistently without failure in Linux after the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add latch for tooltip hide and mouse move events It still fails the first time I run it. I ran it on a physical machine, and I now know why. I can make it fail every time by moving the mouse away from the center of the screen (so that it is outside of where the window will appear). The problem is that the tooltip will not show up on Linux if you directly move the cursor with Robot to be over the control without it ever having been somewhere else in the window first. So the only reason it works on subsequent runs is that the mouse is left in a position such that it will be over the window when the test is run the next time. In general, it's also a good idea to click in the window to ensure that it is activated. The only other robot-based test that shows a Tooltip first moves the mouse to the upper-left corner of the scene and then does a mouse click. Adding that code to your patch causes it to work. So I recommend adding the following to the test (in addition to the changes you already made, which look good). diff --git a/tests/system/src/test/java/test/robot/javafx/scene/SliderTooltipNPETest.java b/tests/system/src/test/java/test/robot/javafx/scene/SliderTooltipNPETest.java --- a/tests/system/src/test/java/test/robot/javafx/scene/SliderTooltipNPETest.java +++ b/tests/system/src/test/java/test/robot/javafx/scene/SliderTooltipNPETest.java @@ -88,6 +88,13 @@ public class SliderTooltipNPETest { } private void dragSliderAfterTooltipDisplayed(int dragDistance) throws Exception { + Util.runAndWait(() -> { + // Click somewhere in the Stage to ensure that it is active + robot.mouseMove((int)(scene.getWindow().getX() + scene.getX()), + (int)(scene.getWindow().getY() + scene.getY())); + robot.mouseClick(MouseButton.PRIMARY); + }); + Thread.sleep(1000); // Wait for slider to layout Util.runAndWait(() -> { ------------- Changes requested by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1119#pullrequestreview-1475859562 From jhendrikx at openjdk.org Mon Jun 12 22:06:00 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 12 Jun 2023 22:06:00 GMT Subject: RFR: 8306021: Add event handler management to EventTarget [v5] In-Reply-To: References: <5BIM8D2acRWXNCALew4jS8OrndcHWMWC9-hCDCkvLwI=.f1283fbc-0421-48d1-b81d-b979437d1770@github.com> Message-ID: <_abeYknTOH5HZotoGiUL3kMrPGOCETam5kHO6w6g74o=.6eb03af3-99e8-4cde-927f-52cdbe6f704d@github.com> On Mon, 12 Jun 2023 18:17:17 GMT, Michael Strau? wrote: >> This PR adds the following methods to the `EventTarget` interface: >> 1. `addEventHandler` >> 2. `removeEventHandler` >> 3. `addEventFilter` >> 4. `removeEventFilter` > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - added tests > - Code review changes Marked as reviewed by jhendrikx (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1090#pullrequestreview-1475885940 From kcr at openjdk.org Mon Jun 12 22:57:52 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Jun 2023 22:57:52 GMT Subject: RFR: 8306021: Add event handler management to EventTarget [v5] In-Reply-To: References: <5BIM8D2acRWXNCALew4jS8OrndcHWMWC9-hCDCkvLwI=.f1283fbc-0421-48d1-b81d-b979437d1770@github.com> Message-ID: On Mon, 12 Jun 2023 18:17:17 GMT, Michael Strau? wrote: >> This PR adds the following methods to the `EventTarget` interface: >> 1. `addEventHandler` >> 2. `removeEventHandler` >> 3. `addEventFilter` >> 4. `removeEventFilter` > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - added tests > - Code review changes Looks good. I'll Review the CSR and then you can Finalize it. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1090#pullrequestreview-1475933597 From duke at openjdk.org Mon Jun 12 23:20:49 2023 From: duke at openjdk.org (Martin Fox) Date: Mon, 12 Jun 2023 23:20:49 GMT Subject: RFR: 8278924: [Linux] Robot key test can fail if multiple keyboard layouts are installed [v3] In-Reply-To: References: <5SPjvG13-ikrrvdyb0M7KJNSmvRIM-bWEXTxLNka8Jg=.49267d9e-a893-4251-88ce-667da5567405@github.com> Message-ID: On Mon, 17 Apr 2023 18:13:38 GMT, Martin Fox wrote: >> The Robot implementation on Linux did not consult the current layout when mapping from a KeyCode to a hardware code. Internally it retrieved results for all the layouts but just picked the first one it saw leading to random effects. Though not part of the original bug report, the code also ignored the shift level when choosing which result to pick. On a French layout the dollar sign is on two keys (AltGr 4 is the second one) and the code could choose either one. Same is true for pound. >> >> This PR consults the current layout and only on shift level 0 which is the same level used in get_glass_key to figure out which KeyCode to assign when generating a KeyEvent. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > The Robot code now correctly targets numlock keypad keys and keys that always appear on group 0. Leaving a comment so this pull request isn't closed. Working Robot code is vital for testing other parts of keyboard handling, like #694. ------------- PR Comment: https://git.openjdk.org/jfx/pull/718#issuecomment-1588238000 From mstrauss at openjdk.org Tue Jun 13 04:21:54 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 13 Jun 2023 04:21:54 GMT Subject: Integrated: 8306021: Add event handler management to EventTarget In-Reply-To: <5BIM8D2acRWXNCALew4jS8OrndcHWMWC9-hCDCkvLwI=.f1283fbc-0421-48d1-b81d-b979437d1770@github.com> References: <5BIM8D2acRWXNCALew4jS8OrndcHWMWC9-hCDCkvLwI=.f1283fbc-0421-48d1-b81d-b979437d1770@github.com> Message-ID: On Wed, 12 Apr 2023 18:19:11 GMT, Michael Strau? wrote: > This PR adds the following methods to the `EventTarget` interface: > 1. `addEventHandler` > 2. `removeEventHandler` > 3. `addEventFilter` > 4. `removeEventFilter` This pull request has now been integrated. Changeset: 614dc55f Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/614dc55fa94c1692cfec534220f5b8e97c90cfce Stats: 636 lines in 15 files changed: 245 ins; 323 del; 68 mod 8306021: Add event handler management to EventTarget Reviewed-by: jhendrikx, nlisker, angorya, mhanl, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1090 From kpk at openjdk.org Tue Jun 13 05:54:13 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 13 Jun 2023 05:54:13 GMT Subject: RFR: 8304922: [testbug] SliderTooltipNPETest fails on Linux [v3] In-Reply-To: References: Message-ID: > The test was failing on the first run and then it was not failing. Cause for the failure looked to be the UI state not getting updated. Hence added call to `Toolkit` `firePulse` method. > > Able to run the test consistently without failure in Linux after the fix. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Stabilize test in Linux ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1119/files - new: https://git.openjdk.org/jfx/pull/1119/files/1033f258..08d08a7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1119&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1119&range=01-02 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1119.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1119/head:pull/1119 PR: https://git.openjdk.org/jfx/pull/1119 From kpk at openjdk.org Tue Jun 13 05:54:13 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 13 Jun 2023 05:54:13 GMT Subject: RFR: 8304922: [testbug] SliderTooltipNPETest fails on Linux [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 21:35:46 GMT, Kevin Rushforth wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Add latch for tooltip hide and mouse move events > > It still fails the first time I run it. I ran it on a physical machine, and I now know why. I can make it fail every time by moving the mouse away from the center of the screen (so that it is outside of where the window will appear). > > The problem is that the tooltip will not show up on Linux if you directly move the cursor with Robot to be over the control without it ever having been somewhere else in the window first. So the only reason it works on subsequent runs is that the mouse is left in a position such that it will be over the window when the test is run the next time. > > In general, it's also a good idea to click in the window to ensure that it is activated. The only other robot-based test that shows a Tooltip first moves the mouse to the upper-left corner of the scene and then does a mouse click. Adding that code to your patch causes it to work. > > So I recommend adding the following to the test (in addition to the changes you already made, which look good). > > > diff --git a/tests/system/src/test/java/test/robot/javafx/scene/SliderTooltipNPETest.java b/tests/system/src/test/java/test/robot/javafx/scene/SliderTooltipNPETest.java > --- a/tests/system/src/test/java/test/robot/javafx/scene/SliderTooltipNPETest.java > +++ b/tests/system/src/test/java/test/robot/javafx/scene/SliderTooltipNPETest.java > @@ -88,6 +88,13 @@ public class SliderTooltipNPETest { > } > > private void dragSliderAfterTooltipDisplayed(int dragDistance) throws Exception { > + Util.runAndWait(() -> { > + // Click somewhere in the Stage to ensure that it is active > + robot.mouseMove((int)(scene.getWindow().getX() + scene.getX()), > + (int)(scene.getWindow().getY() + scene.getY())); > + robot.mouseClick(MouseButton.PRIMARY); > + }); > + > Thread.sleep(1000); // Wait for slider to layout > > Util.runAndWait(() -> { Thanks for the suggestion @kevinrushforth. Made changes according to your comments. Please check. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1119#issuecomment-1588586326 From fweimer at openjdk.org Tue Jun 13 08:55:49 2023 From: fweimer at openjdk.org (Florian Weimer) Date: Tue, 13 Jun 2023 08:55:49 GMT Subject: RFR: 8307542: Call to FcConfigAppFontAddFile uses wrong prototype, arguments In-Reply-To: References: Message-ID: On Fri, 5 May 2023 15:56:40 GMT, Florian Weimer wrote: > Related to: > > * https://fedoraproject.org/wiki/Changes/PortingToModernC > * https://fedoraproject.org/wiki/Toolchain/PortingToModernC @prrace @kevinrushforth Any chance to get this reviewed? Thanks. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1128#issuecomment-1588845801 From kcr at openjdk.org Tue Jun 13 11:25:53 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Jun 2023 11:25:53 GMT Subject: RFR: 8299348: Size-restricted window can be observed with incorrect dimensions [v2] In-Reply-To: References: <9zNyOtonYujDxiJZQQs_Xtx8ewS63NLff04eebFzEWU=.8ddb924d-d8cd-49bb-a61e-ec2c447c9ad0@github.com> Message-ID: On Sat, 13 May 2023 17:22:53 GMT, Michael Strau? wrote: >> On Windows, a `Stage` that is restricted by minimum and maximum sizes can briefly be observed to appear with incorrect dimensions when it is first shown. The root cause of this bug is that the native `WinWindow._setBounds` method doesn't respect min/max sizes when calculating the window rect. >> >> Note to reviewers: I've removed the unused `GlassWindow::updateMinMaxSize` method as to not confuse readers where min-max handling actually happens. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments @arapte can you be the primary reviewer on this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/984#issuecomment-1589105129 From kcr at openjdk.org Tue Jun 13 13:02:48 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Jun 2023 13:02:48 GMT Subject: RFR: 8304922: [testbug] SliderTooltipNPETest fails on Linux [v3] In-Reply-To: References: Message-ID: On Tue, 13 Jun 2023 05:54:13 GMT, Karthik P K wrote: >> The test was failing on the first run and then it was not failing. Cause for the failure looked to be the UI state not getting updated. Hence added call to `Toolkit` `firePulse` method. >> >> Able to run the test consistently without failure in Linux after the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Stabilize test in Linux Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1119#pullrequestreview-1477117037 From kpk at openjdk.org Tue Jun 13 13:36:54 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 13 Jun 2023 13:36:54 GMT Subject: Integrated: 8304922: [testbug] SliderTooltipNPETest fails on Linux In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 12:06:51 GMT, Karthik P K wrote: > The test was failing on the first run and then it was not failing. Cause for the failure looked to be the UI state not getting updated. Hence added call to `Toolkit` `firePulse` method. > > Able to run the test consistently without failure in Linux after the fix. This pull request has now been integrated. Changeset: 72be85ec Author: Karthik P K URL: https://git.openjdk.org/jfx/commit/72be85ec8621ecf93c48305ffc833803d9a4558f Stats: 21 lines in 1 file changed: 16 ins; 2 del; 3 mod 8304922: [testbug] SliderTooltipNPETest fails on Linux Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1119 From fkirmaier at openjdk.org Tue Jun 13 13:59:24 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 13 Jun 2023 13:59:24 GMT Subject: RFR: 8309935: Mac - SystemMenuBar, IndexOutOfBoundsException on change Message-ID: Fixing JDK-8309935 and providing a test for it. ------------- Commit messages: - Fixing JDK-8309935 and providing a test for it. Changes: https://git.openjdk.org/jfx/pull/1152/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1152&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309935 Stats: 93 lines in 2 files changed: 92 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1152.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1152/head:pull/1152 PR: https://git.openjdk.org/jfx/pull/1152 From jgneff at openjdk.org Tue Jun 13 14:27:32 2023 From: jgneff at openjdk.org (John Neffenger) Date: Tue, 13 Jun 2023 14:27:32 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v15] In-Reply-To: References: Message-ID: > This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: > > > $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) > $ bash gradlew sdk jmods javadoc > $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod > > > The three commands: > > 1. set the build timestamp to the date of the latest source code change, > 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and > 3. recreate the JMOD files with stable file modification times and ordering. > > The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. > > #### Fixes > > There are at least four sources of non-determinism in the JavaFX builds: > > 1. Build timestamp > > The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. > > 2. Modification times > > The JAR, JMOD, and ZIP archives store the modification time of each file. > > 3. File ordering > > The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. > > 4. Build path > > The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. > > This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Merge branch 'master' into allow-reproducible-builds - Merge branch 'master' into allow-reproducible-builds - Revert format of timestamp in version OPT field - Merge branch 'master' into allow-reproducible-builds Include two commits that fix WebKit build failures on Windows and macOS: 8282359: Intermittent WebKit build failure on Windows: C1090: PDB API call failed, error code 23 8286089: Intermittent WebKit build failure on macOS in JavaScriptCore - Merge branch 'master' into allow-reproducible-builds - Support JDK 17 GA or later for building JavaFX - Merge branch 'master' into allow-reproducible-builds - Add '--date' argument for deterministic JMOD files - Merge branch 'master' into allow-reproducible-builds - Merge branch 'master' into allow-reproducible-builds - ... and 14 more: https://git.openjdk.org/jfx/compare/72be85ec...fd39e6d1 ------------- Changes: https://git.openjdk.org/jfx/pull/446/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=446&range=14 Stats: 154 lines in 7 files changed: 123 ins; 13 del; 18 mod Patch: https://git.openjdk.org/jfx/pull/446.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/446/head:pull/446 PR: https://git.openjdk.org/jfx/pull/446 From jgneff at openjdk.org Tue Jun 13 14:39:57 2023 From: jgneff at openjdk.org (John Neffenger) Date: Tue, 13 Jun 2023 14:39:57 GMT Subject: RFR: 8307316: Let JavaFX be built on unknown architectures [v2] In-Reply-To: References: Message-ID: <0050_dkkBoPts0EoSUAHCE6ZqV4KifO02QEAjGyZclE=.58e7ea3d-0334-4821-b809-ba0592a9658e@github.com> > Please review these changes to the Gradle build files and the dependency verification file. The initial version of this pull request extends the permitted build platforms for Linux to the Java architectures `arm`, `ppc64le`, and `s390x` and adds an entry to the dependency verification file for the `i386` architecture. The Debian names for these architectures are `armhf`, `i386`, `ppc64el`, and `s390x`. John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into allow-armhf-i386-ppc64el-s390x - Warn instead of failing on unknown architectures - Merge branch 'master' into allow-armhf-i386-ppc64el-s390x - Merge branch 'master' into allow-armhf-i386-ppc64el-s390x - Allow building on armhf, i386, ppc64el, and s390x ------------- Changes: https://git.openjdk.org/jfx/pull/1124/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1124&range=01 Stats: 9 lines in 3 files changed: 5 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1124.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1124/head:pull/1124 PR: https://git.openjdk.org/jfx/pull/1124 From kcr at openjdk.org Tue Jun 13 15:04:52 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Jun 2023 15:04:52 GMT Subject: RFR: 8309935: Mac - SystemMenuBar, IndexOutOfBoundsException on change In-Reply-To: References: Message-ID: <1Jm4NCB7U_zcSkVuZXdiQwVjlbYG_9w4u38mnFWTeTU=.6d96f1c4-9678-4a55-8411-12c4e14904d1@github.com> On Tue, 13 Jun 2023 13:52:46 GMT, Florian Kirmaier wrote: > Fixing JDK-8309935 and providing a test for it. The fix and the test look OK to me. Have you tested it on all platforms (including Linux and Windows, which will ignore the attempt to use a system menu bar, but should otherwise behave as expected)? I left a couple inline comments. tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 1: > 1: package test.javafx.stage; This needs a standard copyright header. tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 7: > 5: import org.junit.Test; > 6: import test.util.Util; > 7: import test.util.memory.JMemoryBuddy; Unused import. ------------- PR Review: https://git.openjdk.org/jfx/pull/1152#pullrequestreview-1477388941 PR Review Comment: https://git.openjdk.org/jfx/pull/1152#discussion_r1228268233 PR Review Comment: https://git.openjdk.org/jfx/pull/1152#discussion_r1228282730 From kcr at openjdk.org Tue Jun 13 15:08:01 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Jun 2023 15:08:01 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v15] In-Reply-To: References: Message-ID: On Tue, 13 Jun 2023 14:27:32 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: > > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - Revert format of timestamp in version OPT field > - Merge branch 'master' into allow-reproducible-builds > > Include two commits that fix WebKit build failures on Windows and macOS: > > 8282359: Intermittent WebKit build failure on Windows: > C1090: PDB API call failed, error code 23 > 8286089: Intermittent WebKit build failure on macOS in JavaScriptCore > - Merge branch 'master' into allow-reproducible-builds > - Support JDK 17 GA or later for building JavaFX > - Merge branch 'master' into allow-reproducible-builds > - Add '--date' argument for deterministic JMOD files > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - ... and 14 more: https://git.openjdk.org/jfx/compare/72be85ec...fd39e6d1 Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/446#pullrequestreview-1477420957 From jgneff at openjdk.org Tue Jun 13 16:56:58 2023 From: jgneff at openjdk.org (John Neffenger) Date: Tue, 13 Jun 2023 16:56:58 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v13] In-Reply-To: References: <_WXDVDoiGezrJmltUlcPkKflohZhoWjwjYQedH93PIE=.65682e52-8f40-47f3-8cfd-ce0251ebac97@github.com> <39uWZaDlwuSdF-6_lMOlhcE6o5QYJPp4jdr4DEG8pxA=.81aa31a8-2f19-44c9-8cda-d164f8c869ad@github.com> Message-ID: <-L3e2pZFsWeJnexAkDghUyeuZJdI-dj6MSaTxn_jL1I=.945aaeb6-83c2-4fcb-a2e0-cb5951470d5f@github.com> On Fri, 28 Apr 2023 01:24:51 GMT, John Neffenger wrote: >> I solved the build failure occurring on Windows by downgrading to Visual Studio 2022 [Build Tools version 17.1.0][1], dated February 15, 2022, from the prior version 17.5.4 that I was using. I opened a bug report, linked below, as a *heads-up* for when we upgrade Visual Studio. >> >> I'm now using the following versions of the tools: >> >> #### Toolchains >> >> * **Linux:** gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0 >> * **macOS:** Command Line Tools for Xcode 14.2 version 14.2.0.0.1.1668646533 >> * **Windows:** Visual Studio Build Tools 2022 version 17.1.0, build number 17.1.32210.238 >> >> #### Build Tools >> >> * **JDK:** OpenJDK Runtime Environment (build 19.0.2+7-44) >> * **Ant:** Apache Ant(TM) version 1.10.13 compiled on January 4 2023 >> * **CMake:** cmake version 3.26.3 >> >> My latest test results are: >> >> | System | Develop | Actions | Release | Notes | >> |:-------:|:-------:|:-------:|:-------:| ------------------------- | >> | Linux | ? | ? | ? | `libjfxwebkit.so` differs | >> | macOS | ? | ? | ? | Just luck, I suspect. | >> | Windows | ? | ? | ? | `jfxwebkit.dll` differs | >> >> where: >> >> * ? means that all of the files in the `build` directory were identical between the two consecutive builds, and the unit tests ran successfully, while >> * ? means that there were differences in the native libraries between the two builds. >> >> I created bug reports to track each of the remaining potential problems: >> >> * [JDK-8306884][2]: Building WebKit on Linux is not deterministic >> * [JDK-8306885][3]: Building WebKit on Windows is not deterministic >> * [JDK-8306886][4]: Building macOS libraries can be non-deterministic >> * [JDK-8306887][5]: Error C2327 while compiling WebKit on Windows >> >> [1]: https://learn.microsoft.com/en-us/visualstudio/releases/2022/release-history#fixed-version-bootstrappers >> [2]: https://bugs.openjdk.org/browse/JDK-8306884 >> [3]: https://bugs.openjdk.org/browse/JDK-8306885 >> [4]: https://bugs.openjdk.org/browse/JDK-8306886 >> [5]: https://bugs.openjdk.org/browse/JDK-8306887 > >> I created bug reports to track each of the remaining potential problems: > > I forgot the original remaining problem! It's listed as item 4 under **Fixes** in the description at the top of this pull request and now described by the following bug report: > > * [JDK-8307082](https://bugs.openjdk.org/browse/JDK-8307082): Build path is recorded in JavaFX Controls module > @jgneff Can you merge in the latest master? This will pick up the recent compiler updates along with any other recent changes. Thank you, Kevin, for your patience while I was away on vacation. I'll also give this another test, at least on Linux, as my own final review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/446#issuecomment-1589689383 From kcr at openjdk.org Tue Jun 13 17:46:55 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Jun 2023 17:46:55 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v20] In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 01:09:36 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Insert copyright Thanks for the explanation about why you had to change the tests. The latest fix looks good. All my testing is green. Running the new `StartIconified` manual test reveals two problems: 1. On Windows there is a brief flash where the window is visible before it is iconified -- we should file a P4 bug 2. On macOS 13 (not sure about 12) the Stage is not iconified at all -- this is tracked by [JDK-8305675](https://bugs.openjdk.org/browse/JDK-8305675) ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1110#pullrequestreview-1462939278 From kcr at openjdk.org Tue Jun 13 17:46:56 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Jun 2023 17:46:56 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v4] In-Reply-To: <9-lI8EjvcncSI3Z34gd3XUfScnsZQjwGDe3wTnrxRYk=.6b88b961-b9e7-4e68-8b42-db1dd9e2c729@github.com> References: <9-lI8EjvcncSI3Z34gd3XUfScnsZQjwGDe3wTnrxRYk=.6b88b961-b9e7-4e68-8b42-db1dd9e2c729@github.com> Message-ID: <3HzFHmCI2wqVzErdQV7iw8puyRVZZHcGwW-g7z_eISc=.1033e7ac-3c41-49a5-a3ce-cc0152a3e6d0@github.com> On Mon, 24 Apr 2023 11:25:28 GMT, Jose Pereda wrote: >> Now I see that the call will actually get delayed. >> >> `javafx.stage.Window` will do the calls when the window will be shown(). On line 1162 `WindowStage.setScene` is called: >> >> >> peer.setScene(SceneHelper.getPeer(getScene())); >> >> >> but this is only called on line 1186: >> >> >> peer.setVisible(true); >> >> >> The configuration of Window properties (iconified, maximized, etc) will start on line 1212: >> >> >> WindowHelper.visibleChanged(Window.this, newVisible); >> >> >> which will fall into `Stage` line 1178 `doVisibleChanged`. >> >> I think this is the right place to call `requestFocus` if the window is not minimized/iconified. >> >> Calling `requestFocus` on `setScene` will cause an initially iconified window to be shown (actually pop on the screen) and then be iconified. > > @tsayao Unrelated to this PR, but I see that your master is [38 commits ahead](https://github.com/tsayao/jfx/compare/openjdk:jfx:master...master) of openjdk:master. > This is causing that for every new branch and PR that you create, those commits (the first 30 ones date from 3 years ago!) are always added to it. > Could you reset your local master branch to the upstream version? @jperedadnr This should now be ready for you to resume your review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1589762949 From kcr at openjdk.org Tue Jun 13 17:46:59 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Jun 2023 17:46:59 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v18] In-Reply-To: <90Qbdi_mFQbCH7sn5q1Jf_wJbWa9HK_QWDWyRoRAeGk=.350ee310-1ad4-4cd8-bb0f-67e5cf0084a1@github.com> References: <90Qbdi_mFQbCH7sn5q1Jf_wJbWa9HK_QWDWyRoRAeGk=.350ee310-1ad4-4cd8-bb0f-67e5cf0084a1@github.com> Message-ID: <8NwI8H_MTRSQqFjydCVHa3SpGStaCNnSrdhFh8_kMG0=.9d25da8f-1502-4454-9f75-0b878fa81481@github.com> On Sun, 4 Jun 2023 18:48:29 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Unchanged line modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkWindow.java line 51: > 49: // empty - not needed by this implementation > 50: @Override > 51: protected void _updateViewSize(long ptr) {} Are you sure that this is no longer needed on Linux in all cases? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1110#discussion_r1218314123 From kcr at openjdk.org Tue Jun 13 17:46:59 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Jun 2023 17:46:59 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v18] In-Reply-To: <8NwI8H_MTRSQqFjydCVHa3SpGStaCNnSrdhFh8_kMG0=.9d25da8f-1502-4454-9f75-0b878fa81481@github.com> References: <90Qbdi_mFQbCH7sn5q1Jf_wJbWa9HK_QWDWyRoRAeGk=.350ee310-1ad4-4cd8-bb0f-67e5cf0084a1@github.com> <8NwI8H_MTRSQqFjydCVHa3SpGStaCNnSrdhFh8_kMG0=.9d25da8f-1502-4454-9f75-0b878fa81481@github.com> Message-ID: On Mon, 5 Jun 2023 16:27:44 GMT, Kevin Rushforth wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Unchanged line > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkWindow.java line 51: > >> 49: // empty - not needed by this implementation >> 50: @Override >> 51: protected void _updateViewSize(long ptr) {} > > Are you sure that this is no longer needed on Linux in all cases? The above was an old comment, please ignore it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1110#discussion_r1228487153 From kcr at openjdk.org Tue Jun 13 17:56:54 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Jun 2023 17:56:54 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v4] In-Reply-To: <9-lI8EjvcncSI3Z34gd3XUfScnsZQjwGDe3wTnrxRYk=.6b88b961-b9e7-4e68-8b42-db1dd9e2c729@github.com> References: <9-lI8EjvcncSI3Z34gd3XUfScnsZQjwGDe3wTnrxRYk=.6b88b961-b9e7-4e68-8b42-db1dd9e2c729@github.com> Message-ID: On Mon, 24 Apr 2023 11:25:28 GMT, Jose Pereda wrote: >> Now I see that the call will actually get delayed. >> >> `javafx.stage.Window` will do the calls when the window will be shown(). On line 1162 `WindowStage.setScene` is called: >> >> >> peer.setScene(SceneHelper.getPeer(getScene())); >> >> >> but this is only called on line 1186: >> >> >> peer.setVisible(true); >> >> >> The configuration of Window properties (iconified, maximized, etc) will start on line 1212: >> >> >> WindowHelper.visibleChanged(Window.this, newVisible); >> >> >> which will fall into `Stage` line 1178 `doVisibleChanged`. >> >> I think this is the right place to call `requestFocus` if the window is not minimized/iconified. >> >> Calling `requestFocus` on `setScene` will cause an initially iconified window to be shown (actually pop on the screen) and then be iconified. > > @tsayao Unrelated to this PR, but I see that your master is [38 commits ahead](https://github.com/tsayao/jfx/compare/openjdk:jfx:master...master) of openjdk:master. > This is causing that for every new branch and PR that you create, those commits (the first 30 ones date from 3 years ago!) are always added to it. > Could you reset your local master branch to the upstream version? > @jperedadnr This should now be ready for you to resume your review. When you do, can you confirm whether [JDK-8304734](https://bugs.openjdk.org/browse/JDK-8304734) and [JDK-8304476](https://bugs.openjdk.org/browse/JDK-8304476) are also fixed? If so, we can close them as a duplicate of [JDK-8306121](https://bugs.openjdk.org/browse/JDK-8306121). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1589777558 From duke at openjdk.org Tue Jun 13 18:24:11 2023 From: duke at openjdk.org (Martin Fox) Date: Tue, 13 Jun 2023 18:24:11 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v6] In-Reply-To: References: Message-ID: > The algorithm in `KeyCharacterCombination.match` relies on the call `Toolkit.getKeyCodeForChar` which is difficult to implement correctly. It defies the way most keyboard API?s work and no platform has got it right yet. In particular the Mac and Linux implementations have to resort to a brute-force approach which monitors keystrokes to learn the relationship between keys and characters. > > This PR introduces an alternative mechanism which directly asks the platform whether a given key can generate a specific character. It also allows the platform to attach identifying key information to each KeyEvent to make it easier to answer the question (much, much easier). > > This is mostly dumb plumbing. On the front-end there?s a new call `View.notifyKeyEx` that takes an additional platform-specific `hardwareCode` parameter. It also returns a boolean indicating whether the event was consumed or not so I can fix JDK-8087863. If you want to follow the path visit the files in this order: > > View.java > GlassViewEventHandler.java > TKSceneListener.java > Scene.java > > The `KeyEvent` class has been expanded with an additional `hardwareCode` member that can only be accessed internally. See KeyEvent.java and KeyEventHelper.java. > > On the back-end `KeyCharacterCombination.match` calls a new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the `KeyEvent` information and sends it on to the Application. The default implementation falls back to the old `getKeyCodeForChar` call but platform specific Applications can send it on to the native glass code. > > KeyCharacterCombination.java > Toolkit.java > QuantumToolkit.java > Application.java > GtkApplication.java > > The glass code can use the `hardwareCode` to answer the question directly. It also has enough information to fall back on the old `getKeyCodeForChar` logic while also enabling the keypad (a common complaint is that Ctrl+?+? only works on the main keyboard and not the keypad, see JDK-8090275). > > This PR improves the situation for key events generated by keystrokes. Manually constructed key events won?t work any better or worse than they already do. Based on the bug database I don't think this is an issue. Martin Fox has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge remote-tracking branch 'upstream/master' into scancode - Added comments providing instructions. - Updating classpath for Eclipse users - New Linux implementation of getKeyCanGenerateCharacter that is more performant and correctly handles the numeric keypad. Removed restrictions in the test app that are no longer relevant. Corrected some comments and other minor cleanup. - Merge remote-tracking branch 'upstream/master' into scancode - Added manual test for KeyCharacterCombination matching - New KeyCharacterCombination implementation ------------- Changes: https://git.openjdk.org/jfx/pull/694/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=694&range=05 Stats: 502 lines in 18 files changed: 455 ins; 9 del; 38 mod Patch: https://git.openjdk.org/jfx/pull/694.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/694/head:pull/694 PR: https://git.openjdk.org/jfx/pull/694 From prr at openjdk.org Tue Jun 13 20:16:55 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 13 Jun 2023 20:16:55 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v9] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: On Mon, 5 Jun 2023 11:16:52 GMT, Karthik P K wrote: >> Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. >> >> Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. >> The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. >> >> Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add out of bound check for insertion index Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1091#pullrequestreview-1477983896 From kpk at openjdk.org Wed Jun 14 05:08:12 2023 From: kpk at openjdk.org (Karthik P K) Date: Wed, 14 Jun 2023 05:08:12 GMT Subject: Integrated: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs In-Reply-To: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: On Fri, 14 Apr 2023 07:35:33 GMT, Karthik P K wrote: > Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. > > Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. > The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. > > Added system test to validate the fix. This pull request has now been integrated. Changeset: c20f6d0f Author: Karthik P K URL: https://git.openjdk.org/jfx/commit/c20f6d0f0133a59a982959ee2e48809f30f3130b Stats: 408 lines in 3 files changed: 407 ins; 0 del; 1 mod 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs Reviewed-by: angorya, prr ------------- PR: https://git.openjdk.org/jfx/pull/1091 From alexsch at openjdk.org Wed Jun 14 09:29:08 2023 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Wed, 14 Jun 2023 09:29:08 GMT Subject: RFR: 8087370: [odroid] Monocle: Touch is still broken on Odroid In-Reply-To: <8r1cERIcJeZVLWYcG3EqWV7zKEoDqtLLgqBVHlPIUyI=.9f7e72c8-de1a-49f6-9df2-8d6a5f46174a@github.com> References: <8r1cERIcJeZVLWYcG3EqWV7zKEoDqtLLgqBVHlPIUyI=.9f7e72c8-de1a-49f6-9df2-8d6a5f46174a@github.com> Message-ID: On Wed, 13 Oct 2021 10:52:40 GMT, Fabian Wolter wrote: > There are sometimes multitouch events detected, when only a single touch should be detected under certain conditions. This lead to touch events on previous touch positions. > > The referenced bug is closed with "won't fix" with the justification it would be platform specific. But this is not correct. It affects all Linux platforms combined with a touch controller, which sends the touch events in an uncommon, but valid(!), order. > > We encountered this problem with the touch controller ILI2511 with firmware V6000_V1 in the Tianma display TM070JVHG33. This patch fixes the problem. It is the same patch attached to above bug report. I can try to look at the test. Is the `TouchEventLookaheadTest` a good example for writing a TouchEvent test? https://github.com/openjdk/jfx/blob/c20f6d0f0133a59a982959ee2e48809f30f3130b/tests/system/src/test/java/test/robot/com/sun/glass/ui/monocle/TouchEventLookaheadTest.java#L42 ------------- PR Comment: https://git.openjdk.org/jfx/pull/641#issuecomment-1590831990 From kcr at openjdk.org Wed Jun 14 13:36:18 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jun 2023 13:36:18 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v20] In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 01:09:36 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Insert copyright I filed https://bugs.openjdk.org/browse/JDK-8310029 to track the brief flash on Windows platforms. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1591220606 From kcr at openjdk.org Wed Jun 14 13:45:09 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jun 2023 13:45:09 GMT Subject: RFR: 8310024: Skip failing scene change tests on macOS Message-ID: <35ikO7jxRLNoy60p4nTaLsqVNvQd0AFocPXhrqhKfwk=.3955dff1-ecc2-4a62-a76e-ee408299d1b6@github.com> Simple fix to skip two failing tests on macOS until the underlying bugs are fixed: SceneChangeEventsTest::testSceneChange -- [JDK-8300094](https://bugs.openjdk.org/browse/JDK-8300094) SceneChangeShouldNotFocusStageTest::windowShouldRemainIconified -- [JDK-8305675](https://bugs.openjdk.org/browse/JDK-8305675) With this patch, we now get a clean test run on macOS 12 and 13. ------------- Commit messages: - 8310024: Skip failing scene change tests on macOS Changes: https://git.openjdk.org/jfx/pull/1153/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1153&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310024 Stats: 13 lines in 2 files changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1153.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1153/head:pull/1153 PR: https://git.openjdk.org/jfx/pull/1153 From jpereda at openjdk.org Wed Jun 14 15:35:19 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 14 Jun 2023 15:35:19 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v20] In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 01:09:36 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Insert copyright Looks good Tested on macOS and Linux (with known issue on macOS), and Android, so indeed https://bugs.openjdk.org/browse/JDK-8304476 can be closed as duplicated. I haven't tested Monocle/TestFX though. I have minor comments only. modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/MouseEventFirerTest.java line 277: > 275: setLeftAnchor(bottomRight, 0.); > 276: > 277: content = new AnchorPane(center, topLeft, bottomRight); update license header modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 1131: > 1129: comboBox.requestFocus(); > 1130: > 1131: var kFirer = new KeyEventFirer(comboBox); update license header modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 1192: > 1190: if (!isIconified()) { > 1191: peer.requestFocus(); > 1192: } This works fine on Android. modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1327: > 1325: void WindowContextTop::update_view_size() { > 1326: // Notify the view size only if size is oriented by WINDOW, otherwise > 1327: // it knows it's own size minor: `s/it's/its` tests/manual/stage/StartIconified.java line 37: > 35: * If the stage pops on the Screen and then iconifies, it's wrong. > 36: */ > 37: public class StartIconified extends Application { Should we mention this doesn't work on macOS until https://bugs.openjdk.org/browse/JDK-8305675 gets fixed? ------------- PR Review: https://git.openjdk.org/jfx/pull/1110#pullrequestreview-1479636142 PR Review Comment: https://git.openjdk.org/jfx/pull/1110#discussion_r1229760146 PR Review Comment: https://git.openjdk.org/jfx/pull/1110#discussion_r1229768464 PR Review Comment: https://git.openjdk.org/jfx/pull/1110#discussion_r1229778730 PR Review Comment: https://git.openjdk.org/jfx/pull/1110#discussion_r1229730263 PR Review Comment: https://git.openjdk.org/jfx/pull/1110#discussion_r1229790900 From angorya at openjdk.org Wed Jun 14 15:38:10 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Jun 2023 15:38:10 GMT Subject: RFR: 8310024: Skip failing scene change tests on macOS In-Reply-To: <35ikO7jxRLNoy60p4nTaLsqVNvQd0AFocPXhrqhKfwk=.3955dff1-ecc2-4a62-a76e-ee408299d1b6@github.com> References: <35ikO7jxRLNoy60p4nTaLsqVNvQd0AFocPXhrqhKfwk=.3955dff1-ecc2-4a62-a76e-ee408299d1b6@github.com> Message-ID: On Wed, 14 Jun 2023 13:39:52 GMT, Kevin Rushforth wrote: > Simple fix to skip two failing tests on macOS until the underlying bugs are fixed: > > SceneChangeEventsTest::testSceneChange -- [JDK-8300094](https://bugs.openjdk.org/browse/JDK-8300094) > SceneChangeShouldNotFocusStageTest::windowShouldRemainIconified -- [JDK-8305675](https://bugs.openjdk.org/browse/JDK-8305675) > > With this patch, we now get a clean test run on macOS 12 and 13. tests/system/src/test/java/test/robot/javafx/scene/SceneChangeShouldNotFocusStageTest.java line 69: > 67: public static void exit() { > 68: if (stage != null) { > 69: Util.shutdown(stage); I wonder if we should move the null check to Util.shutdown() to make things easier ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1153#discussion_r1229822503 From kcr at openjdk.org Wed Jun 14 16:02:04 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jun 2023 16:02:04 GMT Subject: RFR: 8310024: Skip failing scene change tests on macOS In-Reply-To: References: <35ikO7jxRLNoy60p4nTaLsqVNvQd0AFocPXhrqhKfwk=.3955dff1-ecc2-4a62-a76e-ee408299d1b6@github.com> Message-ID: <_w1WVK28l6IunExQE33_py1Pf9TOa5hQPGAXRPFmKlI=.898cf38d-924e-4213-b760-fe1eb3577615@github.com> On Wed, 14 Jun 2023 15:35:40 GMT, Andy Goryachev wrote: >> Simple fix to skip two failing tests on macOS until the underlying bugs are fixed: >> >> SceneChangeEventsTest::testSceneChange -- [JDK-8300094](https://bugs.openjdk.org/browse/JDK-8300094) >> SceneChangeShouldNotFocusStageTest::windowShouldRemainIconified -- [JDK-8305675](https://bugs.openjdk.org/browse/JDK-8305675) >> >> With this patch, we now get a clean test run on macOS 12 and 13. > > tests/system/src/test/java/test/robot/javafx/scene/SceneChangeShouldNotFocusStageTest.java line 69: > >> 67: public static void exit() { >> 68: if (stage != null) { >> 69: Util.shutdown(stage); > > I wonder if we should move the null check to Util.shutdown() to make things easier Maybe. If so, we would also need a check to avoid calling shutdown if the platform was never started. In this specific case, I know that if the stage is null, then the platform was not started, but the utility method could not make that assumption. In any case, I would want to do it as a follow-up RFE for the test utility and not part of a simple test exclusion bug fix. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1153#discussion_r1229854371 From aghaisas at openjdk.org Wed Jun 14 16:11:02 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 14 Jun 2023 16:11:02 GMT Subject: RFR: 8310024: Skip failing scene change tests on macOS In-Reply-To: <35ikO7jxRLNoy60p4nTaLsqVNvQd0AFocPXhrqhKfwk=.3955dff1-ecc2-4a62-a76e-ee408299d1b6@github.com> References: <35ikO7jxRLNoy60p4nTaLsqVNvQd0AFocPXhrqhKfwk=.3955dff1-ecc2-4a62-a76e-ee408299d1b6@github.com> Message-ID: <9cZhAVtZAK3KdefYgXMkQp2Je_D1J8tJ5XBcfkut4H4=.44e2e301-12fb-4ef7-8094-e62d0e49adff@github.com> On Wed, 14 Jun 2023 13:39:52 GMT, Kevin Rushforth wrote: > Simple fix to skip two failing tests on macOS until the underlying bugs are fixed: > > SceneChangeEventsTest::testSceneChange -- [JDK-8300094](https://bugs.openjdk.org/browse/JDK-8300094) > SceneChangeShouldNotFocusStageTest::windowShouldRemainIconified -- [JDK-8305675](https://bugs.openjdk.org/browse/JDK-8305675) > > With this patch, we now get a clean test run on macOS 12 and 13. Looks good. ------------- Marked as reviewed by aghaisas (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1153#pullrequestreview-1479841807 From angorya at openjdk.org Wed Jun 14 16:13:26 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Jun 2023 16:13:26 GMT Subject: RFR: 8302511: HitInfo.toString() throws IllegalArgumentException Message-ID: A recent change in JDK-8304831 ensured that insertionIndex is always computed prior to HitInfo construction, making it possible to remove buggy logic in HitInfo. This change also allows for removal of the 'text' field. There should be no impact since the constructor is package protected. ------------- Commit messages: - no change - Merge branch 'master' into 8302511.hit.info - 8302511: HitInfo.toString() throws IllegalArgumentException - 8194704: Text/TextFlow hitTest() javadoc - Merge master to resolve merge conflict - Stabilizing the system tests - Add new test. Optimizations to make the tests robust - Change insertion index initialization approach. Add additional test - Initialize insertion index in PrismTextLayout - Address code review - ... and 2 more: https://git.openjdk.org/jfx/compare/c20f6d0f...c2685ba7 Changes: https://git.openjdk.org/jfx/pull/1154/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1154&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8302511 Stats: 48 lines in 3 files changed: 3 ins; 27 del; 18 mod Patch: https://git.openjdk.org/jfx/pull/1154.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1154/head:pull/1154 PR: https://git.openjdk.org/jfx/pull/1154 From kcr at openjdk.org Wed Jun 14 16:19:04 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jun 2023 16:19:04 GMT Subject: RFR: 8302511: HitInfo.toString() throws IllegalArgumentException In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 15:40:41 GMT, Andy Goryachev wrote: > A recent change in JDK-8304831 ensured that insertionIndex is always computed prior to HitInfo construction, making it possible to remove buggy logic in HitInfo. This change also allows for removal of the 'text' field. > > There should be no impact since the constructor is package protected. Reviewers: @prrace @karthikpandelu ------------- PR Comment: https://git.openjdk.org/jfx/pull/1154#issuecomment-1591587694 From kcr at openjdk.org Wed Jun 14 16:22:07 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jun 2023 16:22:07 GMT Subject: RFR: 8302511: HitInfo.toString() throws IllegalArgumentException In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 15:40:41 GMT, Andy Goryachev wrote: > A recent change in JDK-8304831 ensured that insertionIndex is always computed prior to HitInfo construction, making it possible to remove buggy logic in HitInfo. This change also allows for removal of the 'text' field. > > There should be no impact since the constructor is package protected. The fix looks good to me, but I'll let Phil and Karthik formally review it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1154#issuecomment-1591590817 From kcr at openjdk.org Wed Jun 14 16:27:05 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jun 2023 16:27:05 GMT Subject: RFR: 8307542: Call to FcConfigAppFontAddFile uses wrong prototype, arguments In-Reply-To: References: Message-ID: On Tue, 13 Jun 2023 08:52:42 GMT, Florian Weimer wrote: >> Related to: >> >> * https://fedoraproject.org/wiki/Changes/PortingToModernC >> * https://fedoraproject.org/wiki/Toolchain/PortingToModernC > > @prrace @kevinrushforth Any chance to get this reviewed? Thanks. @fweimer-rh The fix looks good to me. Please enable GitHub Actions on your personal fork. Then merge in the latest upstream master into your branch, both to trigger a GHA run, and to do so with the latest compiler updates and any other recent changes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1128#issuecomment-1591600329 From fweimer at openjdk.org Wed Jun 14 16:50:35 2023 From: fweimer at openjdk.org (Florian Weimer) Date: Wed, 14 Jun 2023 16:50:35 GMT Subject: RFR: 8307542: Call to FcConfigAppFontAddFile uses wrong prototype, arguments [v2] In-Reply-To: References: Message-ID: <6L9-Po5hVNL0ooOEuCv3mM313d7qjCZZKehaLBDu2hs=.7f76d6ba-2957-4c31-80e2-fa9c86d94396@github.com> > Related to: > > * https://fedoraproject.org/wiki/Changes/PortingToModernC > * https://fedoraproject.org/wiki/Toolchain/PortingToModernC Florian Weimer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8307542: Call to FcConfigAppFontAddFile uses wrong prototype, arguments ------------- Changes: https://git.openjdk.org/jfx/pull/1128/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1128&range=01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1128.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1128/head:pull/1128 PR: https://git.openjdk.org/jfx/pull/1128 From angorya at openjdk.org Wed Jun 14 16:57:05 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Jun 2023 16:57:05 GMT Subject: RFR: 8310024: Skip failing scene change tests on macOS In-Reply-To: <35ikO7jxRLNoy60p4nTaLsqVNvQd0AFocPXhrqhKfwk=.3955dff1-ecc2-4a62-a76e-ee408299d1b6@github.com> References: <35ikO7jxRLNoy60p4nTaLsqVNvQd0AFocPXhrqhKfwk=.3955dff1-ecc2-4a62-a76e-ee408299d1b6@github.com> Message-ID: On Wed, 14 Jun 2023 13:39:52 GMT, Kevin Rushforth wrote: > Simple fix to skip two failing tests on macOS until the underlying bugs are fixed: > > SceneChangeEventsTest::testSceneChange -- [JDK-8300094](https://bugs.openjdk.org/browse/JDK-8300094) > SceneChangeShouldNotFocusStageTest::windowShouldRemainIconified -- [JDK-8305675](https://bugs.openjdk.org/browse/JDK-8305675) > > With this patch, we now get a clean test run on macOS 12 and 13. headful test run on macOS 13.3.1(a) passes ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1153#pullrequestreview-1479920552 From fweimer at openjdk.org Wed Jun 14 17:05:19 2023 From: fweimer at openjdk.org (Florian Weimer) Date: Wed, 14 Jun 2023 17:05:19 GMT Subject: RFR: 8307542: Call to FcConfigAppFontAddFile uses wrong prototype, arguments [v3] In-Reply-To: References: Message-ID: > Related to: > > * https://fedoraproject.org/wiki/Changes/PortingToModernC > * https://fedoraproject.org/wiki/Toolchain/PortingToModernC Florian Weimer has updated the pull request incrementally with one additional commit since the last revision: Trigger automation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1128/files - new: https://git.openjdk.org/jfx/pull/1128/files/1eceff24..f149ccd2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1128&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1128&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1128.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1128/head:pull/1128 PR: https://git.openjdk.org/jfx/pull/1128 From fweimer at openjdk.org Wed Jun 14 17:05:21 2023 From: fweimer at openjdk.org (Florian Weimer) Date: Wed, 14 Jun 2023 17:05:21 GMT Subject: RFR: 8307542: Call to FcConfigAppFontAddFile uses wrong prototype, arguments In-Reply-To: References: Message-ID: On Tue, 13 Jun 2023 08:52:42 GMT, Florian Weimer wrote: >> Related to: >> >> * https://fedoraproject.org/wiki/Changes/PortingToModernC >> * https://fedoraproject.org/wiki/Toolchain/PortingToModernC > > @prrace @kevinrushforth Any chance to get this reviewed? Thanks. > @fweimer-rh Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. Sorry, I forgot about that. There weren't any reviewer comments so far, so no harm done? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1128#issuecomment-1591661524 From kcr at openjdk.org Wed Jun 14 17:13:04 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jun 2023 17:13:04 GMT Subject: RFR: 8307542: Call to FcConfigAppFontAddFile uses wrong prototype, arguments In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 17:00:41 GMT, Florian Weimer wrote: > Sorry, I forgot about that. There weren't any reviewer comments so far, so no harm done? Right. Merging would have made it easier for me to check that there were no changes relative to your earlier commit, but this is a simple-enough fix that it's OK. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1128#issuecomment-1591678905 From kcr at openjdk.org Wed Jun 14 17:23:06 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jun 2023 17:23:06 GMT Subject: RFR: 8307542: Call to FcConfigAppFontAddFile uses wrong prototype, arguments [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 17:05:19 GMT, Florian Weimer wrote: >> Related to: >> >> * https://fedoraproject.org/wiki/Changes/PortingToModernC >> * https://fedoraproject.org/wiki/Toolchain/PortingToModernC > > Florian Weimer has updated the pull request incrementally with one additional commit since the last revision: > > Trigger automation Looks good. GHA run passed (using gcc 12) ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1128#pullrequestreview-1479962946 From kcr at openjdk.org Wed Jun 14 17:26:06 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jun 2023 17:26:06 GMT Subject: Integrated: 8310024: Skip failing scene change tests on macOS In-Reply-To: <35ikO7jxRLNoy60p4nTaLsqVNvQd0AFocPXhrqhKfwk=.3955dff1-ecc2-4a62-a76e-ee408299d1b6@github.com> References: <35ikO7jxRLNoy60p4nTaLsqVNvQd0AFocPXhrqhKfwk=.3955dff1-ecc2-4a62-a76e-ee408299d1b6@github.com> Message-ID: On Wed, 14 Jun 2023 13:39:52 GMT, Kevin Rushforth wrote: > Simple fix to skip two failing tests on macOS until the underlying bugs are fixed: > > SceneChangeEventsTest::testSceneChange -- [JDK-8300094](https://bugs.openjdk.org/browse/JDK-8300094) > SceneChangeShouldNotFocusStageTest::windowShouldRemainIconified -- [JDK-8305675](https://bugs.openjdk.org/browse/JDK-8305675) > > With this patch, we now get a clean test run on macOS 12 and 13. This pull request has now been integrated. Changeset: 8d13ba93 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/8d13ba93b5f01768a6ac2df81c6e026d3d85c86d Stats: 13 lines in 2 files changed: 11 ins; 0 del; 2 mod 8310024: Skip failing scene change tests on macOS Reviewed-by: aghaisas, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1153 From jgneff at openjdk.org Wed Jun 14 18:37:07 2023 From: jgneff at openjdk.org (John Neffenger) Date: Wed, 14 Jun 2023 18:37:07 GMT Subject: RFR: 8307316: Let JavaFX be built on unknown architectures [v2] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 21:24:18 GMT, Kevin Rushforth wrote: >> John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - Merge branch 'master' into allow-armhf-i386-ppc64el-s390x >> - Warn instead of failing on unknown architectures >> - Merge branch 'master' into allow-armhf-i386-ppc64el-s390x >> - Merge branch 'master' into allow-armhf-i386-ppc64el-s390x >> - Allow building on armhf, i386, ppc64el, and s390x > > buildSrc/linux.gradle line 48: > >> 46: "-Wextra", "-Wall", "-Wformat-security", "-Wno-unused", "-Wno-parentheses", "-Werror=trampolines"] // warning flags >> 47: >> 48: if (OS_ARCH == "i386") { > > Why was this change needed, and is it sufficient? It seems that there is a larger problem (likely out of scope for this fix) as to how `IS_64` is set that might need follow-up. The change was needed because the `-m32` option is appropriate only for the `i386` architecture. I believe the change is sufficient, but there does seem to be a problem in how the `IS_64` property is set and used throughout the build files. The property is set with: ext.IS_64 = OS_ARCH.toLowerCase().contains("64") Among the Java architecture names known to the build file or supported by Debian, that means: * `IS_64` is true for `amd64`, `aarch64`, `ppc64le`, `loongarch64`, and `riscv64`, while * `IS_64` is false for `arm`, `i386`, and `s390x`. The previous code, then, would set the `-m32` option for `arm`, `i386`, and `s390x`. Yet the option is valid only for the [following target machines][1]: * RS/6000 and PowerPC (Debian `powerpc`) * SPARC (Debian `sparc`) * x86 (Debian `i386`) So as long as nobody wants to build JavaFX for the 32-bit PowerPC or 32-bit SPARC architectures, the code change is fine. I don't know of anyone still supporting operating systems with Java on those architectures, so we should be safe. [1]: https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1124#discussion_r1230020859 From kevin.rushforth at oracle.com Wed Jun 14 18:47:02 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 14 Jun 2023 11:47:02 -0700 Subject: Platform preferences API Message-ID: <0ede2b26-10db-94cd-0c88-40abea6fc663@oracle.com> I'm finally catching up on the platform preferences API discussion, most of which is in Draft PR #1014 [1]. The information captured here [2] provides a good summary of the API. A PR isn't really the best place to discuss the question of whether this feature is useful and whether the API is heading in the direction we want, so I wanted to have a high level discussion of that here. First of all, I do see the value in having some way to provide the platform-specific properties like colors, etc, to the user. I'm less sure that the same class should also allow overriding those properties, but I can see the value of providing *some* way for the application to override them. In order to move this forward, we need to answer the following questions: 1. Is this functionality something we want in the core of JavaFX? I think the answer is "yes", and it seems like others agree. 2. What is the best way to expose this capability? Currently it is proposed as an interface that extends ObservableMap (meaning that it *is* a Map rather than *contains* a map or has some other map-like representation). This seems fine to me, based on the discussion in the PR. 3. Should the platform preferences API provide the ability to set the properties (to override them) or should that capability be provided some other way (e.g., by some other class)? Perhaps this belongs as part of an eventual theming API, possibly via a "user preferences" class that extends or wraps the platform preferences class? At least the currently proposed API moved away from the odd "override" semantics and uses the standard "put" semantics. That, coupled with the two "reset" methods is a reasonable API, but I'm still not convinced that the core platform preferences class is the place for it. Please consider whether having a separate user / theme preferences interface / class, in addition to the (read-only) system preferences, might be better. 4. Is an Appearance enum the best way to provide the indication of LIGHT vs DARK? Do we need it as part of the Preferences API or should it wait until one of the later RFEs? 5. How do you anticipate this be used by an application prior to having CSS themes? -- Kevin [1] https://github.com/openjdk/jfx/pull/1014 [2] https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548#platform-preferences From kcr at openjdk.org Wed Jun 14 19:38:08 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jun 2023 19:38:08 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v2] In-Reply-To: <1ybACQTFTQ4PqtoPyikEJ0WM0i6p-Sou3BOBKOpCrrA=.fdfe08aa-9458-4e6b-a099-2331a89bf951@github.com> References: <1ybACQTFTQ4PqtoPyikEJ0WM0i6p-Sou3BOBKOpCrrA=.fdfe08aa-9458-4e6b-a099-2331a89bf951@github.com> Message-ID: On Mon, 27 Mar 2023 14:36:45 GMT, John Hendrikx wrote: >> Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Move Subscription method for invalidations to Observable > > - moved Subscription class to the Observable package I reviewed the proposal in the JBS enhancement and the proposed API in this PR. I think this would be a useful addition to JavaFX. I left a few questions and comments. modules/javafx.base/src/main/java/javafx/beans/Subscription.java line 76: > 74: * @return a combined {@code Subscription} which will cancel both when > 75: * cancelled, never {@code null} > 76: * @throws NullPointerException when {@code other} is {@code null} Maybe add a sentence that says that this is equivalent to `Subscription.combine(this, other)`? modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 339: > 337: * @since 21 > 338: */ > 339: default Subscription values(Consumer subscriber) { Same question about the names: we might want to consider a name that has "add" or "subscribe" in the name. modules/javafx.base/src/test/java/test/javafx/beans/SubscriptionTest.java line 1: > 1: package test.javafx.beans; Needs a standard copyright header. modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueSubscriptionsTest.java line 1: > 1: package test.javafx.beans.value; Needs a standard copyright header. ------------- PR Review: https://git.openjdk.org/jfx/pull/1069#pullrequestreview-1480154322 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1230076228 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1230078584 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1230079004 PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1230079093 From kcr at openjdk.org Wed Jun 14 19:38:10 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jun 2023 19:38:10 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v2] In-Reply-To: References: <1ybACQTFTQ4PqtoPyikEJ0WM0i6p-Sou3BOBKOpCrrA=.fdfe08aa-9458-4e6b-a099-2331a89bf951@github.com> Message-ID: On Thu, 20 Apr 2023 08:28:20 GMT, John Hendrikx wrote: >> These example would probably look like this in the near future: >> ``` java >> minimumWidthProperty().addListener(this::requestLayout()); >> minimumWidthProperty().addListener(_ -> this.requestLayout()); >> >> selectedItem.addListener(getSelectionModel()::select); >> selectedItem.addListener((_, _, value) -> gelectionModel().select(value)); >> >> modelStatus.addListener(statusLabel.textProperty()::set); >> modelStatus.addListener((_, _, value) -> statusLabel.setText(value)); >> >> >> You can always ignore the `Observable` parameter, but you can't bring it back once it's gone. I have often used this parameter, for example when my listener handles changes of multiple similar properties. Removing functionality just to make it look a little prettier is not enough justification in my opinion. >> >> If a subscription shouldn't be removable by passing the listener to `removeListener`, this can easily be achieved by internally wrapping it into another listener (just what you did, only with the functional interface being different). However, this might not be the best solution, as it doubles the number of listener objects when using the subscription API. > > Yeah I'm aware they want to add this, but it doesn't really invalidate my point as that syntax is terrible still. Method references are far preferred whenever possible. > > I stand by my point that using the observable parameter is a rare and quite advanced use case, where these API's would be intended to make it easier and safer to use method references and lambda's. > > When dealing with multiple listeners that require the `Observable`, you are likely also dealing with adding and removing that single listener in some dynamic fashion. Subscriptions don't work well with this as you'd need to track these, unlike `removeListener` which you can just pass the single listener reference. > > Here's one of the only examples in JavaFX that uses the observable parameter (if you know of others, I'd be interested to see those as well): > > private final ChangeListener paneFocusListener = new ChangeListener<>() { > @Override public void changed(ObservableValue observable, Boolean oldValue, Boolean newValue) { > if (newValue) { > final ReadOnlyBooleanProperty focusedProperty = (ReadOnlyBooleanProperty) observable; > final TitledPane tp = (TitledPane) focusedProperty.getBean(); > focus(accordion.getPanes().indexOf(tp)); > } > } > }; > > And its management code: > > private final ListChangeListener panesListener = c -> { > while (c.next()) { > if (c.wasAdded()) { > for (final TitledPane tp: c.getAddedSubList()) { > tp.focusedProperty().addListener(paneFocusListener); > } > } else if (c.wasRemoved()) { > for (final TitledPane tp: c.getRemoved()) { > tp.focusedProperty().removeListener(paneFocusListener); > } > } > } > }; > > To do this with `Subscription::unsubscribe` you'd need to track the `Subscriptions`... something like: > > private final Map, Subscription> subscriptions = new HashMap<>(); > private final ListChangeListener panesListener = c -> { > while (c.next()) { > if (c.wasAdded()) { > for (final TitledPane tp: c.getAddedSubList()) { > subscriptions.put(tp.focusedProperty(), tp.focusedProperty().changes(paneFocusListener)); > ... I think the three newly added methods are a good choice. I wonder if we can some up with better names, though. without some verb like "add" or "subscribe" in the name, the name doesn't really indicate that it is adding a new listener to the observable. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1230071655 From kcr at openjdk.org Wed Jun 14 19:38:12 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jun 2023 19:38:12 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v2] In-Reply-To: References: <1ybACQTFTQ4PqtoPyikEJ0WM0i6p-Sou3BOBKOpCrrA=.fdfe08aa-9458-4e6b-a099-2331a89bf951@github.com> Message-ID: On Mon, 17 Apr 2023 23:42:37 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Move Subscription method for invalidations to Observable >> >> - moved Subscription class to the Observable package > > modules/javafx.base/src/main/java/javafx/beans/Subscription.java line 51: > >> 49: * @throws NullPointerException when {@code subscriptions} is {@code null} or contains {@code null} >> 50: */ >> 51: static Subscription of(Subscription... subscriptions) { > > `combine` sounds like a better name to me. I agree that `combine` is a better name. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1230073055 From kevin.rushforth at oracle.com Wed Jun 14 19:55:10 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 14 Jun 2023 12:55:10 -0700 Subject: Proposed schedule for JavaFX 21 In-Reply-To: <854a5a1a-b9a9-cbcb-9866-7d715b199de6@oracle.com> References: <854a5a1a-b9a9-cbcb-9866-7d715b199de6@oracle.com> Message-ID: As a reminder, Rampdown Phase 1 (RDP1) for JavaFX 21 starts on July 13, 2023 at 16:00 UTC (09:00 Pacific time), about four weeks from now. Please allow sufficient time for any feature that needs a CSR. Given that we are entering the summer holiday season, and with the upcoming July 4th US holiday, there may be some delays. New features should be far enough along in the review process that you can finalize the CSR by Thursday, June 29, or it is likely to miss the window for this release, in which case it can be targeted for JavaFX 22. During rampdown of JavaFX 21, the "master" branch of the jfx repo will be open for JavaFX 22 fixes, including enhancements. We will follow a slightly amended process from previous releases for getting fixes into JavaFX 21 during rampdown. I'll send a message with detailed information when we fork, but the major change is that we will follow the recently-adopted JDK process for handling backports during stabilization. See these messages [1] [2] for more information. 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 appropriately high for such requests. -- Kevin [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-May/007889.html [2] https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007911.html On 4/10/2023 9:44 AM, Kevin Rushforth wrote: > Here is the proposed schedule for JavaFX 21. > > RDP1: Jul 13, 2023 (aka ?feature freeze?) > RDP2: Aug 3, 2023 > Freeze: Aug 31, 2023 > GA: Sep 19, 2023 > > We plan to fork a jfx21 stabilization branch at RDP1. > > 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 dwookey at openjdk.org Thu Jun 15 07:11:11 2023 From: dwookey at openjdk.org (Dean Wookey) Date: Thu, 15 Jun 2023 07:11:11 GMT Subject: RFR: 8283551: ControlAcceleratorSupport menu items listener causes memory leak [v2] In-Reply-To: <-EO0_ALVkCo1LxR72uB5U__Lpd9NYOzrrsIc9HXPsM4=.77e4d3f5-56ca-4716-b66f-2e5517196abc@github.com> References: <-EO0_ALVkCo1LxR72uB5U__Lpd9NYOzrrsIc9HXPsM4=.77e4d3f5-56ca-4716-b66f-2e5517196abc@github.com> Message-ID: On Wed, 1 Mar 2023 13:36:46 GMT, Kevin Rushforth wrote: >> Dean Wookey has updated the pull request incrementally with one additional commit since the last revision: >> >> Added more comments and fixed IdentityWrapper hashcode. > > @arapte can you be the second reviewer? @kevinrushforth are there any other reviewers who could look at this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1037#issuecomment-1592484555 From wjbarton at protonmail.com Thu Jun 15 09:53:41 2023 From: wjbarton at protonmail.com (William Barton) Date: Thu, 15 Jun 2023 09:53:41 +0000 Subject: Fixing TextFlow selection fill (JDK-8149134) Message-ID: I've recently run into JDK-8149134: when a Text node has been added to a TextFlow, the Text node's selectionStart and selectionEnd properties are interpreted relative to the whole TextFlow rather than the individual span, which means that a selectionFill color may be applied in the wrong place. This prevents rich-text controls implementing the same text-selection appearance as regular TextAreas. The bug was originally reported against JavaFX 8 but the relevant code appears to behave identically in the current git master. I'd like to get this fixed -- it looks like a fairly simple task, as the JBS report already identifies a solution (and I suspect the implementation can be simplified, since the Text.spanOffset function added in the JBS draft patch appears to be recalculating information already available from TextRun.getStart). Is anyone already working on this? If not, would it be appropriate at this point for me to update the patch, add tests, and open a PR, or is further discussion required first? Thanks, -- Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsayao at openjdk.org Thu Jun 15 12:16:20 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 15 Jun 2023 12:16:20 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v21] In-Reply-To: References: Message-ID: > I replicated the fix on #1054 on Linux. > > Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Review changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1110/files - new: https://git.openjdk.org/jfx/pull/1110/files/89a77e96..322e75c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=20 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=19-20 Stats: 6 lines in 4 files changed: 2 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1110.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1110/head:pull/1110 PR: https://git.openjdk.org/jfx/pull/1110 From tsayao at openjdk.org Thu Jun 15 12:16:21 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 15 Jun 2023 12:16:21 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v4] In-Reply-To: <9-lI8EjvcncSI3Z34gd3XUfScnsZQjwGDe3wTnrxRYk=.6b88b961-b9e7-4e68-8b42-db1dd9e2c729@github.com> References: <9-lI8EjvcncSI3Z34gd3XUfScnsZQjwGDe3wTnrxRYk=.6b88b961-b9e7-4e68-8b42-db1dd9e2c729@github.com> Message-ID: On Mon, 24 Apr 2023 11:25:28 GMT, Jose Pereda wrote: >> Now I see that the call will actually get delayed. >> >> `javafx.stage.Window` will do the calls when the window will be shown(). On line 1162 `WindowStage.setScene` is called: >> >> >> peer.setScene(SceneHelper.getPeer(getScene())); >> >> >> but this is only called on line 1186: >> >> >> peer.setVisible(true); >> >> >> The configuration of Window properties (iconified, maximized, etc) will start on line 1212: >> >> >> WindowHelper.visibleChanged(Window.this, newVisible); >> >> >> which will fall into `Stage` line 1178 `doVisibleChanged`. >> >> I think this is the right place to call `requestFocus` if the window is not minimized/iconified. >> >> Calling `requestFocus` on `setScene` will cause an initially iconified window to be shown (actually pop on the screen) and then be iconified. > > @tsayao Unrelated to this PR, but I see that your master is [38 commits ahead](https://github.com/tsayao/jfx/compare/openjdk:jfx:master...master) of openjdk:master. > This is causing that for every new branch and PR that you create, those commits (the first 30 ones date from 3 years ago!) are always added to it. > Could you reset your local master branch to the upstream version? @jperedadnr Did the changes requested in review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1592926231 From jpereda at openjdk.org Thu Jun 15 12:25:14 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 15 Jun 2023 12:25:14 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v21] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 12:16:20 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Review changes Looks good to me! ------------- Marked as reviewed by jpereda (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1110#pullrequestreview-1481439584 From kcr at openjdk.org Thu Jun 15 12:56:17 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Jun 2023 12:56:17 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v21] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 12:16:20 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Review changes Copyright year changes are incorrect. modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/MouseEventFirerTest.java line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. No, we never remove the start year in a copyright line. this should be: `2020, 2023,` Alternatively, you can just revert this change, since we will run a script to update them all. Either is fine. modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 2: > 1: /* > 2: * Copyright (c) 2011, 2023, Oracle and/or its affiliates. All rights reserved. `2022, 2023,` ------------- Changes requested by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1110#pullrequestreview-1481491145 PR Review Comment: https://git.openjdk.org/jfx/pull/1110#discussion_r1230961089 PR Review Comment: https://git.openjdk.org/jfx/pull/1110#discussion_r1230961274 From jpereda at openjdk.org Thu Jun 15 12:56:19 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 15 Jun 2023 12:56:19 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v21] In-Reply-To: References: Message-ID: <_7RuoKkGTM_7-SHGIl9KTOor7maGttbjpHlHXD3NbLw=.3821a5af-f5ed-4615-b7cf-e23cec21f16e@github.com> On Thu, 15 Jun 2023 12:50:07 GMT, Kevin Rushforth wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Review changes > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2011, 2023, Oracle and/or its affiliates. All rights reserved. > > `2022, 2023,` this is one is correct, though? `2011, 2023,` should be fine? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1110#discussion_r1230966654 From kcr at openjdk.org Thu Jun 15 13:01:18 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Jun 2023 13:01:18 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v21] In-Reply-To: <_7RuoKkGTM_7-SHGIl9KTOor7maGttbjpHlHXD3NbLw=.3821a5af-f5ed-4615-b7cf-e23cec21f16e@github.com> References: <_7RuoKkGTM_7-SHGIl9KTOor7maGttbjpHlHXD3NbLw=.3821a5af-f5ed-4615-b7cf-e23cec21f16e@github.com> Message-ID: On Thu, 15 Jun 2023 12:53:39 GMT, Jose Pereda wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2011, 2023, Oracle and/or its affiliates. All rights reserved. >> >> `2022, 2023,` > > this is one is correct, though? `2011, 2023,` should be fine? Sorry, I misread this one. Yes, this one is correct: `2011, 2023,` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1110#discussion_r1230973628 From kpk at openjdk.org Thu Jun 15 14:45:02 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 15 Jun 2023 14:45:02 GMT Subject: RFR: 8302511: HitInfo.toString() throws IllegalArgumentException In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 15:40:41 GMT, Andy Goryachev wrote: > A recent change in JDK-8304831 ensured that insertionIndex is always computed prior to HitInfo construction, making it possible to remove buggy logic in HitInfo. This change also allows for removal of the 'text' field. > > There should be no impact since the constructor is package protected. The fix looks good to me. Can we add a test to verify the changes? Another minor comment: copyright year can be updated in Text.java as well. ------------- PR Review: https://git.openjdk.org/jfx/pull/1154#pullrequestreview-1481756712 From tsayao at openjdk.org Thu Jun 15 16:21:35 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 15 Jun 2023 16:21:35 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v22] In-Reply-To: References: Message-ID: <84JovD5xjwMmcCnhesEy7CldkYulO-9P1RzSf_T7VwU=.fb858b57-f240-498c-9cbd-17da904d9c02@github.com> > I replicated the fix on #1054 on Linux. > > Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix copyright year ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1110/files - new: https://git.openjdk.org/jfx/pull/1110/files/322e75c4..0b516a19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=21 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=20-21 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1110.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1110/head:pull/1110 PR: https://git.openjdk.org/jfx/pull/1110 From kcr at openjdk.org Thu Jun 15 17:10:42 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Jun 2023 17:10:42 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v22] In-Reply-To: <84JovD5xjwMmcCnhesEy7CldkYulO-9P1RzSf_T7VwU=.fb858b57-f240-498c-9cbd-17da904d9c02@github.com> References: <84JovD5xjwMmcCnhesEy7CldkYulO-9P1RzSf_T7VwU=.fb858b57-f240-498c-9cbd-17da904d9c02@github.com> Message-ID: On Thu, 15 Jun 2023 16:21:35 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright year Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1110#pullrequestreview-1482058988 From jpereda at openjdk.org Thu Jun 15 17:14:42 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 15 Jun 2023 17:14:42 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v22] In-Reply-To: <84JovD5xjwMmcCnhesEy7CldkYulO-9P1RzSf_T7VwU=.fb858b57-f240-498c-9cbd-17da904d9c02@github.com> References: <84JovD5xjwMmcCnhesEy7CldkYulO-9P1RzSf_T7VwU=.fb858b57-f240-498c-9cbd-17da904d9c02@github.com> Message-ID: <-GA0cWwRbgJ5PLw0Cl4QuXQouis5vMZbfGbYcf4pCGo=.0a4175fe-5a69-4fb2-a8b1-ebd84b6500b4@github.com> On Thu, 15 Jun 2023 16:21:35 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright year Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1110#pullrequestreview-1482064787 From kcr at openjdk.org Thu Jun 15 18:02:51 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Jun 2023 18:02:51 GMT Subject: RFR: 8283551: ControlAcceleratorSupport menu items listener causes memory leak [v2] In-Reply-To: References: Message-ID: On Fri, 24 Feb 2023 10:04:48 GMT, Dean Wookey wrote: >> Each time a menu would change scenes, a new set of ListChangeListeners would be added to the items in the menu. The bigger problem however is that these list change listeners have a strong reference to the scene which is potentially a much bigger leak. >> >> The first commit was more straightforward, but there are 2 things that might be of concern: >> >> 1. The method removeAcceleratorsFromScene takes in a scene parameter, but it'll remove all the ListChangeListeners attached to it, regardless of which scene was passed in. Something similar happens with changeListenerMap already, so I think it's fine. >> 2. I made the remove method public so that external calls from skins to remove the accelerators would remove the ListChangeListener and also because all the remove methods are public. >> >> After I wrote more tests I realised using the ObservableLists as keys in the WeakHashMaps was a bad idea. If Java had a WeakIdentityHashMap the fix would be simple. The fix is in the second commit. >> >> There are still more issues that stem from the fact that for each anchor there could be multiple menus and the current code doesn't account for that. For example, swapping context menus on a tab doesn't register change listeners on the new context menu because the TabPane itself had a scene change listener already. These other issues could relate to JDK-8268374 https://bugs.openjdk.org/browse/JDK-8268374 and JDK-8283449 https://bugs.openjdk.org/browse/JDK-8283449. One of the issues is related to the fact that there's no logic to remove listeners when Tab/TableColumn's are removed from their associated control (TabPane, TableView, TreeTableView). >> >> I'm looking at these issues, but I think they're dependent on this fix. Either I can add to this PR or I can wait to see what comes out of this and fix them subsequently. > > Dean Wookey has updated the pull request incrementally with one additional commit since the last revision: > > Added more comments and fixed IdentityWrapper hashcode. Ideally, @arapte would be the best reviewer, since he has also fixed memory leaks in this area. If he is not able to look at this in the next few days, then perhaps @aghaisas can? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1037#issuecomment-1593501883 From angorya at openjdk.org Thu Jun 15 18:38:14 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jun 2023 18:38:14 GMT Subject: RFR: 8302511: HitInfo.toString() throws IllegalArgumentException [v2] In-Reply-To: References: Message-ID: > A recent change in JDK-8304831 ensured that insertionIndex is always computed prior to HitInfo construction, making it possible to remove buggy logic in HitInfo. This change also allows for removal of the 'text' field. > > There should be no impact since the constructor is package protected. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1154/files - new: https://git.openjdk.org/jfx/pull/1154/files/c2685ba7..8014ba33 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1154&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1154&range=00-01 Stats: 163 lines in 3 files changed: 140 ins; 7 del; 16 mod Patch: https://git.openjdk.org/jfx/pull/1154.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1154/head:pull/1154 PR: https://git.openjdk.org/jfx/pull/1154 From angorya at openjdk.org Thu Jun 15 18:42:19 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jun 2023 18:42:19 GMT Subject: RFR: 8302511: HitInfo.toString() throws IllegalArgumentException [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 14:42:43 GMT, Karthik P K wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > The fix looks good to me. > Can we add a test to verify the changes? > Another minor comment: copyright year can be updated in Text.java as well. thank you for the suggestions, @karthikpandelu ! - modified TextFlowSurrogatePaitInsertionIndexTest to test for invariants - added a similar test for Text - updated copyright year ------------- PR Comment: https://git.openjdk.org/jfx/pull/1154#issuecomment-1593554489 From jgneff at openjdk.org Thu Jun 15 22:07:20 2023 From: jgneff at openjdk.org (John Neffenger) Date: Thu, 15 Jun 2023 22:07:20 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v15] In-Reply-To: References: Message-ID: On Tue, 13 Jun 2023 14:27:32 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: > > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - Revert format of timestamp in version OPT field > - Merge branch 'master' into allow-reproducible-builds > > Include two commits that fix WebKit build failures on Windows and macOS: > > 8282359: Intermittent WebKit build failure on Windows: > C1090: PDB API call failed, error code 23 > 8286089: Intermittent WebKit build failure on macOS in JavaScriptCore > - Merge branch 'master' into allow-reproducible-builds > - Support JDK 17 GA or later for building JavaFX > - Merge branch 'master' into allow-reproducible-builds > - Add '--date' argument for deterministic JMOD files > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - ... and 14 more: https://git.openjdk.org/jfx/compare/72be85ec...fd39e6d1 I upgraded Visual Studio 2022 to version 17.5.5 on Windows and CMake to version 3.26.4 on all of the platforms, so now I'm using the following tools: ### Toolchains * **Linux:** gcc (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0 * **macOS:** Command Line Tools for Xcode 14.2 version 14.2.0.0.1.1668646533 * **Windows:** Visual Studio Build Tools 2022 version 17.5.5, build number 17.5.33627.172 ### Build Tools * **JDK:** OpenJDK Runtime Environment (build 19.0.2+7-44) * **Ant:** Apache Ant(TM) version 1.10.13 compiled on January 4 2023 * **CMake:** cmake version 3.26.4 I ran the builds as described in the [jgneff/jfxbuild][1] repository. The results are shown below. ### Linux Only the file `libjfxwebkit.so` differs between builds: ubuntu at openjfx:~/src/jfx$ for n in 1,2 3,4 5,6; do (set -x; diff -qr build[$n]); done + diff -qr build1 build2 + diff -qr build3 build4 + diff -qr build5 build6 Files build5/jmods/javafx.web.jmod and build6/jmods/javafx.web.jmod differ Files build5/modular-sdk/modules_libs/javafx.web/libjfxwebkit.so and build6/modular-sdk/modules_libs/javafx.web/libjfxwebkit.so differ Files build5/publications/javafx.web-linux.jar and build6/publications/javafx.web-linux.jar differ Files build5/sdk/lib/libjfxwebkit.so and build6/sdk/lib/libjfxwebkit.so differ ### macOS Only the file `libjavafx_iio.dylib` differs between builds, but I believe that was just by chance. Other test runs often show no differences at all or differences in other native libraries. Xcode version 14.3 may fix these differences, but my late 2014 Mac mini only supports up to Xcode 14.2. john at macwifi:~/src/jfx$ for n in 1,2 3,4 5,6; do (set -x; diff -qr build[$n]); done + diff -qr build1 build2 Files build1/jmods/javafx.graphics.jmod and build2/jmods/javafx.graphics.jmod differ Files build1/modular-sdk/modules_libs/javafx.graphics/libjavafx_iio.dylib and build2/modular-sdk/modules_libs/javafx.graphics/libjavafx_iio.dylib differ Files build1/publications/javafx.graphics-mac.jar and build2/publications/javafx.graphics-mac.jar differ Files build1/sdk/lib/libjavafx_iio.dylib and build2/sdk/lib/libjavafx_iio.dylib differ + diff -qr build3 build4 + diff -qr build5 build6 ### Windows Only the file `jfxwebkit.dll` differs between builds: john at windows:~/src/jfx$ for n in 1,2 3,4 5,6; do (set -x; diff -qr build[$n]); done + diff -qr build1 build2 + diff -qr build3 build4 + diff -qr build5 build6 Files build5/jmods/javafx.web.jmod and build6/jmods/javafx.web.jmod differ Files build5/modular-sdk/modules_libs/javafx.web/jfxwebkit.dll and build6/modular-sdk/modules_libs/javafx.web/jfxwebkit.dll differ Files build5/publications/javafx.web-win.jar and build6/publications/javafx.web-win.jar differ Files build5/sdk/bin/jfxwebkit.dll and build6/sdk/bin/jfxwebkit.dll differ I found another build failure on Windows when running the latest Visual Studio 2022 [Build Tools version 17.6.3][2], dated June 13, 2023. I opened the bug report, "[JDK-8310161][3]: Error C2666 compiling ICU 73.1 with VS 2022 17.6," as a *heads-up* for when we upgrade Visual Studio. [1]: https://github.com/jgneff/jfxbuild [2]: https://learn.microsoft.com/en-us/visualstudio/releases/2022/release-history#fixed-version-bootstrappers [3]: https://bugs.openjdk.org/browse/JDK-8310161 ------------- PR Comment: https://git.openjdk.org/jfx/pull/446#issuecomment-1593779934 From andy.goryachev at oracle.com Thu Jun 15 23:25:07 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 15 Jun 2023 23:25:07 +0000 Subject: Platform preferences API In-Reply-To: <0ede2b26-10db-94cd-0c88-40abea6fc663@oracle.com> References: <0ede2b26-10db-94cd-0c88-40abea6fc663@oracle.com> Message-ID: my two drachmas (in addition to the comments in the PR and elsewhere): #3 I think this API should be unidirectional, i.e. limited to reporting the platform preferences and their runtime changes to the application (the key set is immutable, and values cannot be put by the application). Whenever the applications requires changing of some values by the user/app, the app can create a separate property. #4 I am ok with Appearance enum as long as it's one of the attributes and is present on every supported platform. #5 in my case (programmatic generation of a stylesheet on top of standard modena.css), it can be used to generate derived colors as well as proper effects and highlights. In addition to the questions Kevin asked, I'd like to as 6) Is high contrast mode encoded as another attribute, or does it need two more values in Appearance (high contrast light, high contrast dark)? 7) Is there a way to provide a type-safe interface for retrieving the values from the preferences map? Alternatively, there should be a table for each platform enumerating keys, value types, nullability, and, ideally, a description. Thank you, -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Wednesday, June 14, 2023 at 11:48 To: openjfx-dev Subject: Platform preferences API I'm finally catching up on the platform preferences API discussion, most of which is in Draft PR #1014 [1]. The information captured here [2] provides a good summary of the API. A PR isn't really the best place to discuss the question of whether this feature is useful and whether the API is heading in the direction we want, so I wanted to have a high level discussion of that here. First of all, I do see the value in having some way to provide the platform-specific properties like colors, etc, to the user. I'm less sure that the same class should also allow overriding those properties, but I can see the value of providing *some* way for the application to override them. In order to move this forward, we need to answer the following questions: 1. Is this functionality something we want in the core of JavaFX? I think the answer is "yes", and it seems like others agree. 2. What is the best way to expose this capability? Currently it is proposed as an interface that extends ObservableMap (meaning that it *is* a Map rather than *contains* a map or has some other map-like representation). This seems fine to me, based on the discussion in the PR. 3. Should the platform preferences API provide the ability to set the properties (to override them) or should that capability be provided some other way (e.g., by some other class)? Perhaps this belongs as part of an eventual theming API, possibly via a "user preferences" class that extends or wraps the platform preferences class? At least the currently proposed API moved away from the odd "override" semantics and uses the standard "put" semantics. That, coupled with the two "reset" methods is a reasonable API, but I'm still not convinced that the core platform preferences class is the place for it. Please consider whether having a separate user / theme preferences interface / class, in addition to the (read-only) system preferences, might be better. 4. Is an Appearance enum the best way to provide the indication of LIGHT vs DARK? Do we need it as part of the Preferences API or should it wait until one of the later RFEs? 5. How do you anticipate this be used by an application prior to having CSS themes? -- Kevin [1] https://github.com/openjdk/jfx/pull/1014 [2] https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548#platform-preferences -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Thu Jun 15 23:43:35 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jun 2023 23:43:35 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale Message-ID: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale) (I think). ------------- Commit messages: - whitespace - removed obsolete tester - Merge remote-tracking branch 'origin/master' into 8299753.resize - cleanup - new algorithm Changes: https://git.openjdk.org/jfx/pull/1156/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299753 Stats: 1148 lines in 6 files changed: 137 ins; 926 del; 85 mod Patch: https://git.openjdk.org/jfx/pull/1156.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1156/head:pull/1156 PR: https://git.openjdk.org/jfx/pull/1156 From thiago.sayao at gmail.com Fri Jun 16 00:08:48 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 15 Jun 2023 21:08:48 -0300 Subject: Platform preferences API In-Reply-To: <0ede2b26-10db-94cd-0c88-40abea6fc663@oracle.com> References: <0ede2b26-10db-94cd-0c88-40abea6fc663@oracle.com> Message-ID: I think we should wait and don't do this in the short term. Many recent apps don't care for platform appearance at all. Take Microsoft windows for an example, there are many layers of "evolution" and they all look different on the same OS. Linux will be a nightmare, you have many desktop environments, and if you only consider gnome, it's all CSS based and you can't just obtain a color (because it's on the css). Recent Ubuntu have accent colors, but that's if you use the Yaru theme. If in the future apps start to look the same again we should consider it. The tendency right now seems to be "apps don't have to look the same". Behavior should be consistent, style probably don't. -- Thiago Em qua., 14 de jun. de 2023 15:47, Kevin Rushforth < kevin.rushforth at oracle.com> escreveu: > I'm finally catching up on the platform preferences API discussion, most > of which is in Draft PR #1014 [1]. The information captured here [2] > provides a good summary of the API. > > A PR isn't really the best place to discuss the question of whether this > feature is useful and whether the API is heading in the direction we > want, so I wanted to have a high level discussion of that here. > > First of all, I do see the value in having some way to provide the > platform-specific properties like colors, etc, to the user. I'm less > sure that the same class should also allow overriding those properties, > but I can see the value of providing *some* way for the application to > override them. > > In order to move this forward, we need to answer the following questions: > > 1. Is this functionality something we want in the core of JavaFX? I > think the answer is "yes", and it seems like others agree. > > 2. What is the best way to expose this capability? Currently it is > proposed as an interface that extends ObservableMap (meaning that it > *is* a Map rather than *contains* a map or has some other map-like > representation). This seems fine to me, based on the discussion in the PR. > > 3. Should the platform preferences API provide the ability to set the > properties (to override them) or should that capability be provided some > other way (e.g., by some other class)? Perhaps this belongs as part of > an eventual theming API, possibly via a "user preferences" class that > extends or wraps the platform preferences class? At least the currently > proposed API moved away from the odd "override" semantics and uses the > standard "put" semantics. That, coupled with the two "reset" methods is > a reasonable API, but I'm still not convinced that the core platform > preferences class is the place for it. Please consider whether having a > separate user / theme preferences interface / class, in addition to the > (read-only) system preferences, might be better. > > 4. Is an Appearance enum the best way to provide the indication of LIGHT > vs DARK? Do we need it as part of the Preferences API or should it wait > until one of the later RFEs? > > 5. How do you anticipate this be used by an application prior to having > CSS themes? > > -- Kevin > > [1] https://github.com/openjdk/jfx/pull/1014 > > [2] > > https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548#platform-preferences > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fkirmaier at openjdk.org Fri Jun 16 07:24:51 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Fri, 16 Jun 2023 07:24:51 GMT Subject: RFR: 8309935: Mac - SystemMenuBar, IndexOutOfBoundsException on change [v2] In-Reply-To: References: Message-ID: > Fixing JDK-8309935 and providing a test for it. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: small changes based on code review ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1152/files - new: https://git.openjdk.org/jfx/pull/1152/files/8d9460e7..5ef8357a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1152&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1152&range=00-01 Stats: 27 lines in 1 file changed: 25 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1152.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1152/head:pull/1152 PR: https://git.openjdk.org/jfx/pull/1152 From fkirmaier at openjdk.org Fri Jun 16 07:30:11 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Fri, 16 Jun 2023 07:30:11 GMT Subject: RFR: 8309935: Mac - SystemMenuBar, IndexOutOfBoundsException on change [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 07:24:51 GMT, Florian Kirmaier wrote: >> Fixing JDK-8309935 and providing a test for it. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > small changes based on code review I've tested it on Mac. On Windows, many people will test it soon, because the fix is now integrated into a development version of a JavaFX Application, with a lot of Testers / Developers. So if something breaks, we should know it very soon. But I don't expect any issues. For Linux, I currently don't have a device available to test it. I could create a TestVM, to just Test it, but I don't really see how this breaks only on Linux. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1152#issuecomment-1594236723 From fkirmaier at openjdk.org Fri Jun 16 07:30:15 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Fri, 16 Jun 2023 07:30:15 GMT Subject: RFR: 8309935: Mac - SystemMenuBar, IndexOutOfBoundsException on change [v2] In-Reply-To: <1Jm4NCB7U_zcSkVuZXdiQwVjlbYG_9w4u38mnFWTeTU=.6d96f1c4-9678-4a55-8411-12c4e14904d1@github.com> References: <1Jm4NCB7U_zcSkVuZXdiQwVjlbYG_9w4u38mnFWTeTU=.6d96f1c4-9678-4a55-8411-12c4e14904d1@github.com> Message-ID: <0zfjDD94K8moehxPEpj3m5h4I9YLtZHgpodALxMDexo=.fdd2457b-a07f-4682-b3ab-e423ae8cf85d@github.com> On Tue, 13 Jun 2023 14:53:39 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> small changes based on code review > > tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 1: > >> 1: package test.javafx.stage; > > This needs a standard copyright header. done > tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 7: > >> 5: import org.junit.Test; >> 6: import test.util.Util; >> 7: import test.util.memory.JMemoryBuddy; > > Unused import. done ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1152#discussion_r1231889048 PR Review Comment: https://git.openjdk.org/jfx/pull/1152#discussion_r1231889177 From kpk at openjdk.org Fri Jun 16 08:40:16 2023 From: kpk at openjdk.org (Karthik P K) Date: Fri, 16 Jun 2023 08:40:16 GMT Subject: RFR: 8302511: HitInfo.toString() throws IllegalArgumentException [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jun 2023 18:38:14 GMT, Andy Goryachev wrote: >> A recent change in JDK-8304831 ensured that insertionIndex is always computed prior to HitInfo construction, making it possible to remove buggy logic in HitInfo. This change also allows for removal of the 'text' field. >> >> There should be no impact since the constructor is package protected. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Thanks for updating the test and adding new test @andy-goryachev-oracle. Please check the jcheck failure. I have one minor comment added inline. tests/system/src/test/java/test/robot/javafx/scene/TextSurrogatePairInsertionIndexTest.java line 100: > 98: public static void initFX() { > 99: long seed = new Random().nextLong(); > 100: System.out.println("seed=" + seed); Do we need this print statement? ------------- Changes requested by kpk (Committer). PR Review: https://git.openjdk.org/jfx/pull/1154#pullrequestreview-1483001453 PR Review Comment: https://git.openjdk.org/jfx/pull/1154#discussion_r1231956600 From jhendrikx at openjdk.org Fri Jun 16 09:23:03 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 16 Jun 2023 09:23:03 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v3] In-Reply-To: References: Message-ID: > Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. John Hendrikx has updated the pull request incrementally with three additional commits since the last revision: - Improve javadoc - Add copyright headers - Rename Subscription#of to Subscription#combine ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1069/files - new: https://git.openjdk.org/jfx/pull/1069/files/df31b3fa..23fe903f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=01-02 Stats: 57 lines in 3 files changed: 52 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1069.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1069/head:pull/1069 PR: https://git.openjdk.org/jfx/pull/1069 From jhendrikx at openjdk.org Fri Jun 16 09:28:15 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 16 Jun 2023 09:28:15 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v4] In-Reply-To: References: Message-ID: > Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' of https://git.openjdk.org/jfx into feature/subscriptions - Improve javadoc - Add copyright headers - Rename Subscription#of to Subscription#combine - Move Subscription method for invalidations to Observable - moved Subscription class to the Observable package - Make Subscription public and add methods to provide them ------------- Changes: https://git.openjdk.org/jfx/pull/1069/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=03 Stats: 515 lines in 12 files changed: 381 ins; 122 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/1069.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1069/head:pull/1069 PR: https://git.openjdk.org/jfx/pull/1069 From jhendrikx at openjdk.org Fri Jun 16 09:33:52 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 16 Jun 2023 09:33:52 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v5] In-Reply-To: References: Message-ID: > Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Use forEach ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1069/files - new: https://git.openjdk.org/jfx/pull/1069/files/1d5c1cf6..f1dd27c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=03-04 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1069.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1069/head:pull/1069 PR: https://git.openjdk.org/jfx/pull/1069 From jhendrikx at openjdk.org Fri Jun 16 09:48:10 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 16 Jun 2023 09:48:10 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v2] In-Reply-To: References: <1ybACQTFTQ4PqtoPyikEJ0WM0i6p-Sou3BOBKOpCrrA=.fdfe08aa-9458-4e6b-a099-2331a89bf951@github.com> Message-ID: On Wed, 14 Jun 2023 19:26:01 GMT, Kevin Rushforth wrote: >> Yeah I'm aware they want to add this, but it doesn't really invalidate my point as that syntax is terrible still. Method references are far preferred whenever possible. >> >> I stand by my point that using the observable parameter is a rare and quite advanced use case, where these API's would be intended to make it easier and safer to use method references and lambda's. >> >> When dealing with multiple listeners that require the `Observable`, you are likely also dealing with adding and removing that single listener in some dynamic fashion. Subscriptions don't work well with this as you'd need to track these, unlike `removeListener` which you can just pass the single listener reference. >> >> Here's one of the only examples in JavaFX that uses the observable parameter (if you know of others, I'd be interested to see those as well): >> >> private final ChangeListener paneFocusListener = new ChangeListener<>() { >> @Override public void changed(ObservableValue observable, Boolean oldValue, Boolean newValue) { >> if (newValue) { >> final ReadOnlyBooleanProperty focusedProperty = (ReadOnlyBooleanProperty) observable; >> final TitledPane tp = (TitledPane) focusedProperty.getBean(); >> focus(accordion.getPanes().indexOf(tp)); >> } >> } >> }; >> >> And its management code: >> >> private final ListChangeListener panesListener = c -> { >> while (c.next()) { >> if (c.wasAdded()) { >> for (final TitledPane tp: c.getAddedSubList()) { >> tp.focusedProperty().addListener(paneFocusListener); >> } >> } else if (c.wasRemoved()) { >> for (final TitledPane tp: c.getRemoved()) { >> tp.focusedProperty().removeListener(paneFocusListener); >> } >> } >> } >> }; >> >> To do this with `Subscription::unsubscribe` you'd need to track the `Subscriptions`... something like: >> >> private final Map, Subscription> subscriptions = new HashMap<>(); >> private final ListChangeListener panesListener = c -> { >> while (c.next()) { >> if (c.wasAdded()) { >> for (final TitledPane tp: c.getAddedSubList()) { >> subscriptions.put(tp.foc... > > I think the three newly added methods are a good choice. I wonder if we can some up with better names, though. without some verb like "add" or "subscribe" in the name, the name doesn't really indicate that it is adding a new listener to the observable. I agree that the chosen names `invalidation`, `changes` and `values` are a bit terse. The whole signature (without reading docs) should make it clear you are creating a subscription, but perhaps we can do better. The use of `addListener` can be ruled out as it would conflict with the existing method due to having Lambda's with the same arity (the `values` listener would conflict with `addListener(InvalidationListener)`. Also, an `add` method would probably have users expecting a corresponding `remove` method. A few ideas listed here: | invalidation | values | changes | |---|---|---| |`subscribe(Runnable)`(*)|`subscribe(Consumer)`(*)|`subscribe(BiConsumer)`(*)| |`subscribeInvalidations(Runnable)`|`subscribeValues(Consumer)`|`subscribeChanges(BiConsumer)`| |`invalidationsTo(Runnable)`|`valuesTo(Consumer)`|`changesTo(BiConsumer)`| (*) May limit future listener types that have same arity, but can still be a good choice ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1232029010 From jhendrikx at openjdk.org Fri Jun 16 09:48:11 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 16 Jun 2023 09:48:11 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v2] In-Reply-To: References: <1ybACQTFTQ4PqtoPyikEJ0WM0i6p-Sou3BOBKOpCrrA=.fdfe08aa-9458-4e6b-a099-2331a89bf951@github.com> Message-ID: On Fri, 16 Jun 2023 09:42:45 GMT, John Hendrikx wrote: >> I think the three newly added methods are a good choice. I wonder if we can some up with better names, though. without some verb like "add" or "subscribe" in the name, the name doesn't really indicate that it is adding a new listener to the observable. > > I agree that the chosen names `invalidation`, `changes` and `values` are a bit terse. The whole signature (without reading docs) should make it clear you are creating a subscription, but perhaps we can do better. The use of `addListener` can be ruled out as it would conflict with the existing method due to having Lambda's with the same arity (the `values` listener would conflict with `addListener(InvalidationListener)`. Also, an `add` method would probably have users expecting a corresponding `remove` method. > > A few ideas listed here: > > | invalidation | values | changes | > |---|---|---| > |`subscribe(Runnable)`(*)|`subscribe(Consumer)`(*)|`subscribe(BiConsumer)`(*)| > |`subscribeInvalidations(Runnable)`|`subscribeValues(Consumer)`|`subscribeChanges(BiConsumer)`| > |`invalidationsTo(Runnable)`|`valuesTo(Consumer)`|`changesTo(BiConsumer)`| > > (*) May limit future listener types that have same arity, but can still be a good choice On that same topic of naming methods: What do people think of `Subscription#unsubscribe`? Should it be `cancel`? Something else? Okay as it is? Code example: if (subscription != null) { subscription.unsubscribe(); subscription = null; } ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1232031343 From perini.davide at dpsoftware.org Fri Jun 16 09:52:38 2023 From: perini.davide at dpsoftware.org (Davide Perini) Date: Fri, 16 Jun 2023 11:52:38 +0200 Subject: Windows notifications vanishes Message-ID: Hi all, I know that this a bit off topic but it could be interesting for many JavaFX users. I recently noted that java.awt.TrayIcon.displayMessage() method does not work really well in Windows 11 anymore. My notifications are shown with a strange icon and the notification is not persistent anymore. The notification is shown but then is not persistent in the notifications list as before. Is there someone else who noticed this problem? Any info on how to solve it? Thanks Davide From kcr at openjdk.org Fri Jun 16 11:35:08 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 16 Jun 2023 11:35:08 GMT Subject: RFR: 8307542: Call to FcConfigAppFontAddFile uses wrong prototype, arguments In-Reply-To: References: Message-ID: <2t3A4OuHKG9jYUBuWGuPi9N3pxaaYmMJ_p92std8dBc=.ee65b8f4-45f6-4cfc-a63d-6d51e9a49b40@github.com> On Wed, 14 Jun 2023 17:00:41 GMT, Florian Weimer wrote: >> @prrace @kevinrushforth Any chance to get this reviewed? Thanks. > >> @fweimer-rh Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. > > Sorry, I forgot about that. There weren't any reviewer comments so far, so no harm done? @fweimer-rh For this simple fix, a single reviewer is sufficient. You can `/integrate` this fix when ready. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1128#issuecomment-1594534453 From kevin.rushforth at oracle.com Fri Jun 16 11:41:10 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 16 Jun 2023 04:41:10 -0700 Subject: Fixing TextFlow selection fill (JDK-8149134) In-Reply-To: References: Message-ID: <4b076f04-9c5e-4671-9fb9-676643a090b9@oracle.com> Hi, As far as I know, no one is working on this bug, so if you'd like to contribute a fix based on the initial patch, that would be fine. In addition to adding tests, we would want to see an evaluation that explains why the fix is correct, especially since the comment in the JDK bug says: "It seems to work, but is based on observations rather than an understanding ...". If you haven't already done so, please read the CONTRIBUTING guidelines [1]. Thank you. -- Kevin [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md On 6/15/2023 2:53 AM, William Barton wrote: > I've recently run into JDK-8149134: when a Text node has been added to > a TextFlow, the Text node's selectionStart and selectionEnd properties > are interpreted relative to the whole TextFlow rather than the > individual span, which means that a selectionFill color may be applied > in the wrong place. This prevents rich-text controls implementing the > same text-selection appearance as regular TextAreas. > > The bug was originally reported against JavaFX 8 but the relevant code > appears to behave identically in the current git master. > > I'd like to get this fixed -- it looks like a fairly simple task, as > the JBS report already identifies a solution (and I suspect the > implementation can be simplified, since the Text.spanOffset function > added in the JBS draft patch appears to be recalculating information > already available from TextRun.getStart). > > Is anyone already working on this? If not, would it be appropriate at > this point for me to update the patch, add tests, and open a PR, or is > further discussion required first? > > Thanks, > > -- Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at openjdk.org Fri Jun 16 12:22:13 2023 From: fweimer at openjdk.org (Florian Weimer) Date: Fri, 16 Jun 2023 12:22:13 GMT Subject: Integrated: 8307542: Call to FcConfigAppFontAddFile uses wrong prototype, arguments In-Reply-To: References: Message-ID: On Fri, 5 May 2023 15:56:40 GMT, Florian Weimer wrote: > Related to: > > * https://fedoraproject.org/wiki/Changes/PortingToModernC > * https://fedoraproject.org/wiki/Toolchain/PortingToModernC This pull request has now been integrated. Changeset: 42321838 Author: Florian Weimer Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/42321838b98d2ebb3d8384c88a764ff2b4d70581 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8307542: Call to FcConfigAppFontAddFile uses wrong prototype, arguments Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1128 From michaelstrau2 at gmail.com Fri Jun 16 13:36:06 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 16 Jun 2023 15:36:06 +0200 Subject: Platform preferences API In-Reply-To: <0ede2b26-10db-94cd-0c88-40abea6fc663@oracle.com> References: <0ede2b26-10db-94cd-0c88-40abea6fc663@oracle.com> Message-ID: It might indeed be useful to split read-only platform preferences from mutable application preferences. I've updated the API doc [1]; here is the summary: 1. Have `Platform.getPreferences()` return the same interface as before, minus the mutation methods. 2. Have `Application.getPreferences()` return an extension of the `Platform.Preferences` interface, which includes the mutation methods. The map returned by `Platform.getPreferences()` will only include the preferences that are reported by the platform, while the map returned by `Application.getPreferences()` will also include potentially overridden values. Both maps are updated dynamically when an OS setting is changed, except for overridden values in the `Application.Preferences` map, which will take precedence. [1] https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548#platform-preferences On Wed, Jun 14, 2023 at 8:48?PM Kevin Rushforth wrote: > > 3. Should the platform preferences API provide the ability to set the > properties (to override them) or should that capability be provided some > other way (e.g., by some other class)? Perhaps this belongs as part of > an eventual theming API, possibly via a "user preferences" class that > extends or wraps the platform preferences class? At least the currently > proposed API moved away from the odd "override" semantics and uses the > standard "put" semantics. That, coupled with the two "reset" methods is > a reasonable API, but I'm still not convinced that the core platform > preferences class is the place for it. Please consider whether having a > separate user / theme preferences interface / class, in addition to the > (read-only) system preferences, might be better. > From michaelstrau2 at gmail.com Fri Jun 16 14:41:04 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 16 Jun 2023 16:41:04 +0200 Subject: Platform preferences API In-Reply-To: <0ede2b26-10db-94cd-0c88-40abea6fc663@oracle.com> References: <0ede2b26-10db-94cd-0c88-40abea6fc663@oracle.com> Message-ID: See also Andy's question: > Is high contrast mode encoded as another attribute, or does it need two more values in Appearance (high contrast light, high contrast dark)? LIGHT and DARK are the only two appearances afforded by Windows (starting with Windows 10), macOS, and iOS. I think it's safe to say that the light/dark distinction is here to stay for the forseeable future. We probably shouldn't over-engineer this aspect, especially not by introducing additional appearances like "high contrast light" or "high contrast dark". Keeping this simple allows us to nicely integrate two different APIs: stage.appearanceProperty().bind(Application.getPreferences().appearanceProperty()); If an application wants to support additional themes (high-contrast or entirely custom themes), it can do so with the upcoming StyleTheme API. Having Appearance be an enumeration also allows us to add additional constants if this were to become necessary in the future. I've thought about using sealed interfaces to allow applications to potentially provide their own Appearance implementation: sealed interface Apperance permits Light, Dark { ... non-sealed interface Light extends Appearance {} non-sealed interface Dark extends Appearance {} } This would allow us to encode more bits of information in an Appearance. For example, applications could encode platform-specific hints like corner roundness. But the downside of this is that it's now harder to switch on the light/dark appearance bit. I think it's more sensible to distinguish between three different types of knobs that authors can use to control the look&feel of their application: 1. Knobs that significantly affect the window border and the window content 2. Knobs that significantly affect only the window border 3. Knobs that affect OS-specific details of the window border The first category is represented by Appearance, that's why it gets to have its own enumeration. The second category is represented by StageStyle, because we have broad support on most operating systems. The third category is currently unrepresented, and it includes knobs like DWM_WINDOW_CORNER_PREFERENCE, which is only available on Windows 11. In the future, OS-specific stage details could be controlled with a `Stage.hints` property, which also strongly implies that we are dealing with optional details. In general, we don't need Appearance be part of the first deliverable, we can also add it later with the Stage Decorations RFE. On Wed, Jun 14, 2023 at 8:48?PM Kevin Rushforth wrote: > > 4. Is an Appearance enum the best way to provide the indication of LIGHT > vs DARK? Do we need it as part of the Preferences API or should it wait > until one of the later RFEs? > From michaelstrau2 at gmail.com Fri Jun 16 14:52:47 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 16 Jun 2023 16:52:47 +0200 Subject: Platform preferences API In-Reply-To: References: <0ede2b26-10db-94cd-0c88-40abea6fc663@oracle.com> Message-ID: My perception is entirely different. In the last few years, most operating systems seem to have embraced the light/dark mode concept. More and more applications (as well as web applications) support dark mode in addition to the default light mode, and many try to adapt to the OS. That is certainly true for widely used applications like web browsers, social media apps, and IDEs. It's true that the Linux situation is a bit complicated, but Windows, Apple operating systems, and Android have strong dark mode support. In addition, platform preferences are not only about visual appearance, but can also be relevant for behavioral settings. For example, macOS has an OS setting that controls whether clicking on a scrollbar moves the content page by page, or directly to the clicked spot. Skins could use those kinds of non-visual preferences in the future. On Fri, Jun 16, 2023 at 2:09?AM Thiago Milczarek Say?o wrote: > > I think we should wait and don't do this in the short term. > > Many recent apps don't care for platform appearance at all. > > Take Microsoft windows for an example, there are many layers of "evolution" and they all look different on the same OS. > > Linux will be a nightmare, you have many desktop environments, and if you only consider gnome, it's all CSS based and you can't just obtain a color (because it's on the css). Recent Ubuntu have accent colors, but that's if you use the Yaru theme. > > > If in the future apps start to look the same again we should consider it. The tendency right now seems to be "apps don't have to look the same". > > Behavior should be consistent, style probably don't. > > -- Thiago From dlemmermann at gmail.com Fri Jun 16 15:11:20 2023 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Fri, 16 Jun 2023 17:11:20 +0200 Subject: Platform preferences API In-Reply-To: References: <0ede2b26-10db-94cd-0c88-40abea6fc663@oracle.com> Message-ID: <98A25BE1-EA69-401F-BAC0-A2A296933BA8@gmail.com> I completely disagree. Being able to adjust the applications appearance to the OS has been a topic for me and many others for quite some time. Thanks for people like Gerrit Grunwald I have been able to partially solve dark mode support but it is very OS specific and requires execution of batch code. Being able to simply have an observable would be fantastic. Dirk > Am 16.06.2023 um 02:08 schrieb Thiago Milczarek Say?o : > > I think we should wait and don't do this in the short term. > > Many recent apps don't care for platform appearance at all. > > Take Microsoft windows for an example, there are many layers of "evolution" and they all look different on the same OS. > > Linux will be a nightmare, you have many desktop environments, and if you only consider gnome, it's all CSS based and you can't just obtain a color (because it's on the css). Recent Ubuntu have accent colors, but that's if you use the Yaru theme. > > > If in the future apps start to look the same again we should consider it. The tendency right now seems to be "apps don't have to look the same". > > Behavior should be consistent, style probably don't. > > -- Thiago > > > Em qua., 14 de jun. de 2023 15:47, Kevin Rushforth > escreveu: >> I'm finally catching up on the platform preferences API discussion, most >> of which is in Draft PR #1014 [1]. The information captured here [2] >> provides a good summary of the API. >> >> A PR isn't really the best place to discuss the question of whether this >> feature is useful and whether the API is heading in the direction we >> want, so I wanted to have a high level discussion of that here. >> >> First of all, I do see the value in having some way to provide the >> platform-specific properties like colors, etc, to the user. I'm less >> sure that the same class should also allow overriding those properties, >> but I can see the value of providing *some* way for the application to >> override them. >> >> In order to move this forward, we need to answer the following questions: >> >> 1. Is this functionality something we want in the core of JavaFX? I >> think the answer is "yes", and it seems like others agree. >> >> 2. What is the best way to expose this capability? Currently it is >> proposed as an interface that extends ObservableMap (meaning that it >> *is* a Map rather than *contains* a map or has some other map-like >> representation). This seems fine to me, based on the discussion in the PR. >> >> 3. Should the platform preferences API provide the ability to set the >> properties (to override them) or should that capability be provided some >> other way (e.g., by some other class)? Perhaps this belongs as part of >> an eventual theming API, possibly via a "user preferences" class that >> extends or wraps the platform preferences class? At least the currently >> proposed API moved away from the odd "override" semantics and uses the >> standard "put" semantics. That, coupled with the two "reset" methods is >> a reasonable API, but I'm still not convinced that the core platform >> preferences class is the place for it. Please consider whether having a >> separate user / theme preferences interface / class, in addition to the >> (read-only) system preferences, might be better. >> >> 4. Is an Appearance enum the best way to provide the indication of LIGHT >> vs DARK? Do we need it as part of the Preferences API or should it wait >> until one of the later RFEs? >> >> 5. How do you anticipate this be used by an application prior to having >> CSS themes? >> >> -- Kevin >> >> [1] https://github.com/openjdk/jfx/pull/1014 >> >> [2] >> https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548#platform-preferences >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Jun 16 15:35:42 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 16 Jun 2023 15:35:42 GMT Subject: RFR: 8302511: HitInfo.toString() throws IllegalArgumentException [v3] In-Reply-To: References: Message-ID: > A recent change in JDK-8304831 ensured that insertionIndex is always computed prior to HitInfo construction, making it possible to remove buggy logic in HitInfo. This change also allows for removal of the 'text' field. > > There should be no impact since the constructor is package protected. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: whitespace ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1154/files - new: https://git.openjdk.org/jfx/pull/1154/files/8014ba33..d5fdff40 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1154&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1154&range=01-02 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1154.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1154/head:pull/1154 PR: https://git.openjdk.org/jfx/pull/1154 From angorya at openjdk.org Fri Jun 16 15:38:12 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 16 Jun 2023 15:38:12 GMT Subject: RFR: 8302511: HitInfo.toString() throws IllegalArgumentException [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 08:34:29 GMT, Karthik P K wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > tests/system/src/test/java/test/robot/javafx/scene/TextSurrogatePairInsertionIndexTest.java line 100: > >> 98: public static void initFX() { >> 99: long seed = new Random().nextLong(); >> 100: System.out.println("seed=" + seed); > > Do we need this print statement? yes. I've added a brief comment, but let me explain in more detail: these tests use random patterns to avoid hitting the same values each time. for example, in TextFlowSurrogatePairInsertionIndexTest many tests incremented the x coordinate by 5 prior to this change, but what if we had an error condition happening with x = 21?. the old test never hit that value, but the new one might (at some point). so we effectively extending the test coverage every time the test runs. and, if we ever encounter a failure, it will be possible to reproduce the exact failure scenario by setting the same seed as found in the failed log. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1154#discussion_r1232409636 From thiago.sayao at gmail.com Fri Jun 16 15:45:57 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Fri, 16 Jun 2023 12:45:57 -0300 Subject: Platform preferences API In-Reply-To: References: <0ede2b26-10db-94cd-0c88-40abea6fc663@oracle.com> Message-ID: I was thinking mostly about colors. Those will be hard because the tendency to have css styles. Might not even be a solid color. Light and Dark mode could be useful and seems like a hardened feature everywhere. Maybe a Modena dark css should be shipped together (for optimal use)? -- Thiago Em sex., 16 de jun. de 2023 11:52, Michael Strau? escreveu: > My perception is entirely different. In the last few years, most > operating systems seem to have embraced the light/dark mode concept. > More and more applications (as well as web applications) support dark > mode in addition to the default light mode, and many try to adapt to > the OS. > That is certainly true for widely used applications like web browsers, > social media apps, and IDEs. > > It's true that the Linux situation is a bit complicated, but Windows, > Apple operating systems, and Android have strong dark mode support. > > In addition, platform preferences are not only about visual > appearance, but can also be relevant for behavioral settings. For > example, macOS has an OS setting that controls whether clicking on a > scrollbar moves the content page by page, or directly to the clicked > spot. Skins could use those kinds of non-visual preferences in the > future. > > > On Fri, Jun 16, 2023 at 2:09?AM Thiago Milczarek Say?o > wrote: > > > > I think we should wait and don't do this in the short term. > > > > Many recent apps don't care for platform appearance at all. > > > > Take Microsoft windows for an example, there are many layers of > "evolution" and they all look different on the same OS. > > > > Linux will be a nightmare, you have many desktop environments, and if > you only consider gnome, it's all CSS based and you can't just obtain a > color (because it's on the css). Recent Ubuntu have accent colors, but > that's if you use the Yaru theme. > > > > > > If in the future apps start to look the same again we should consider > it. The tendency right now seems to be "apps don't have to look the same". > > > > Behavior should be consistent, style probably don't. > > > > -- Thiago > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Fri Jun 16 15:55:54 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 16 Jun 2023 17:55:54 +0200 Subject: Platform preferences API In-Reply-To: References: <0ede2b26-10db-94cd-0c88-40abea6fc663@oracle.com> Message-ID: Maybe the Preferences API should have a convenience method like Optional getPaint(String key); instead of getColor, to allow for cases when an OS defines complex paint instead of solid colors. I like your idea of shipping a Modena Dark variant. We should consider this as a potential follow-up RFE. On Fri, Jun 16, 2023 at 5:46?PM Thiago Milczarek Say?o wrote: > > I was thinking mostly about colors. Those will be hard because the tendency to have css styles. Might not even be a solid color. > > Light and Dark mode could be useful and seems like a hardened feature everywhere. Maybe a Modena dark css should be shipped together (for optimal use)? > > -- Thiago From tsayao at openjdk.org Fri Jun 16 15:56:20 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 16 Jun 2023 15:56:20 GMT Subject: Integrated: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 In-Reply-To: References: Message-ID: On Sat, 22 Apr 2023 12:55:05 GMT, Thiago Milczarek Sayao wrote: > I replicated the fix on #1054 on Linux. > > Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) This pull request has now been integrated. Changeset: 7eb9a1c4 Author: Thiago Milczarek Sayao URL: https://git.openjdk.org/jfx/commit/7eb9a1c47926277223fb947d90f2e08e00a9aafd Stats: 116 lines in 8 files changed: 101 ins; 1 del; 14 mod 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 Reviewed-by: jpereda, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1110 From andy.goryachev at oracle.com Fri Jun 16 15:57:53 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 16 Jun 2023 15:57:53 +0000 Subject: Platform preferences API In-Reply-To: References: <0ede2b26-10db-94cd-0c88-40abea6fc663@oracle.com> Message-ID: +1 for getPaint() +1 for modena dark css -andy From: openjfx-dev on behalf of Michael Strau? Date: Friday, June 16, 2023 at 08:56 To: Thiago Milczarek Say?o Cc: openjfx-dev Subject: Re: Platform preferences API Maybe the Preferences API should have a convenience method like Optional getPaint(String key); instead of getColor, to allow for cases when an OS defines complex paint instead of solid colors. I like your idea of shipping a Modena Dark variant. We should consider this as a potential follow-up RFE. On Fri, Jun 16, 2023 at 5:46?PM Thiago Milczarek Say?o wrote: > > I was thinking mostly about colors. Those will be hard because the tendency to have css styles. Might not even be a solid color. > > Light and Dark mode could be useful and seems like a hardened feature everywhere. Maybe a Modena dark css should be shipped together (for optimal use)? > > -- Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Jun 16 16:01:20 2023 From: duke at openjdk.org (Daniel Subelman) Date: Fri, 16 Jun 2023 16:01:20 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v22] In-Reply-To: <84JovD5xjwMmcCnhesEy7CldkYulO-9P1RzSf_T7VwU=.fb858b57-f240-498c-9cbd-17da904d9c02@github.com> References: <84JovD5xjwMmcCnhesEy7CldkYulO-9P1RzSf_T7VwU=.fb858b57-f240-498c-9cbd-17da904d9c02@github.com> Message-ID: <6ABy2L5qkREU3Qp6Jy6bwaJ-3HOc7uFxbO4Y4svCSLo=.8127eb21-116d-47c3-80f5-cc4fb84742a2@github.com> On Thu, 15 Jun 2023 16:21:35 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright year Thanks for fixing this issue. Does this fix also solve the Monocle/TestFX issue? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1594903272 From tsayao at openjdk.org Fri Jun 16 16:12:22 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 16 Jun 2023 16:12:22 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v22] In-Reply-To: <84JovD5xjwMmcCnhesEy7CldkYulO-9P1RzSf_T7VwU=.fb858b57-f240-498c-9cbd-17da904d9c02@github.com> References: <84JovD5xjwMmcCnhesEy7CldkYulO-9P1RzSf_T7VwU=.fb858b57-f240-498c-9cbd-17da904d9c02@github.com> Message-ID: On Thu, 15 Jun 2023 16:21:35 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright year It probably does fix It. But we found out that focus was not working with StubToolkit because the focus call was previously called only on QuantumToolkit. I don't know about TestFx but since the below bug exists (about focus) it probably doesn't use StubToolkit. https://github.com/TestFX/TestFX/issues/749 Em sex., 16 de jun. de 2023 12:53, Daniel Subelman ***@***.***> escreveu: > Thanks for fixing this issue. Does this fix also solve the Monocle/TestFX > issue? > > ? > Reply to this email directly, view it on GitHub > , or > unsubscribe > > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1594924608 From kevin.rushforth at oracle.com Fri Jun 16 20:12:08 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 16 Jun 2023 13:12:08 -0700 Subject: [External] : Re: Platform preferences API In-Reply-To: References: <0ede2b26-10db-94cd-0c88-40abea6fc663@oracle.com> Message-ID: <1d4868fe-d710-9471-fa30-31ae36b30127@oracle.com> I think this is another step in the right direction. The Platform.getPreferences() method would then document that the returned map is an "unmodifiable map" (as defined by the Map interface docs). -- Kevin On 6/16/2023 6:36 AM, Michael Strau? wrote: > It might indeed be useful to split read-only platform preferences from > mutable application preferences. > I've updated the API doc [1]; here is the summary: > 1. Have `Platform.getPreferences()` return the same interface as > before, minus the mutation methods. > 2. Have `Application.getPreferences()` return an extension of the > `Platform.Preferences` interface, which includes the mutation methods. > > The map returned by `Platform.getPreferences()` will only include the > preferences that are reported by the platform, while the map returned > by `Application.getPreferences()` will also include potentially > overridden values. > Both maps are updated dynamically when an OS setting is changed, > except for overridden values in the `Application.Preferences` map, > which will take precedence. > > [1] https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548#platform-preferences > > > On Wed, Jun 14, 2023 at 8:48?PM Kevin Rushforth > wrote: >> 3. Should the platform preferences API provide the ability to set the >> properties (to override them) or should that capability be provided some >> other way (e.g., by some other class)? Perhaps this belongs as part of >> an eventual theming API, possibly via a "user preferences" class that >> extends or wraps the platform preferences class? At least the currently >> proposed API moved away from the odd "override" semantics and uses the >> standard "put" semantics. That, coupled with the two "reset" methods is >> a reasonable API, but I'm still not convinced that the core platform >> preferences class is the place for it. Please consider whether having a >> separate user / theme preferences interface / class, in addition to the >> (read-only) system preferences, might be better. >> From kcr at openjdk.org Sat Jun 17 14:10:30 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 17 Jun 2023 14:10:30 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v20] In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 15:06:20 GMT, Jose Pereda wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Insert copyright > > modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 1192: > >> 1190: if (!isIconified()) { >> 1191: peer.requestFocus(); >> 1192: } > > This works fine on Android. Thanks for confirming. I just now closed [JDK-8304476](https://bugs.openjdk.org/browse/JDK-8304476) as a duplicate of [JDK-8306121](https://bugs.openjdk.org/browse/JDK-8306121). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1110#discussion_r1233067874 From kcr at openjdk.org Sat Jun 17 14:17:28 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 17 Jun 2023 14:17:28 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v22] In-Reply-To: <84JovD5xjwMmcCnhesEy7CldkYulO-9P1RzSf_T7VwU=.fb858b57-f240-498c-9cbd-17da904d9c02@github.com> References: <84JovD5xjwMmcCnhesEy7CldkYulO-9P1RzSf_T7VwU=.fb858b57-f240-498c-9cbd-17da904d9c02@github.com> Message-ID: <7b6NAUW71Lz50twBaescGlRharF4kwbAI24M-El41IA=.bdb37342-441a-4ee6-88b8-da91505e9e2d@github.com> On Thu, 15 Jun 2023 16:21:35 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright year I _think_ [JDK-8304734](https://bugs.openjdk.org/browse/JDK-8304734) can be closed as a duplicate of this bug, but it would be helpful to confirm that it resolves the problem reported in TestFX/TestFX#749. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1595771490 From kpk at openjdk.org Mon Jun 19 05:01:15 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 19 Jun 2023 05:01:15 GMT Subject: RFR: 8302511: HitInfo.toString() throws IllegalArgumentException [v2] In-Reply-To: References: Message-ID: <1OkgeB80BP57gsZesJGBnozPnY84nqKySeub3ULbEHA=.f69b12c3-751c-4667-a999-ff399b2d7e8d@github.com> On Fri, 16 Jun 2023 15:35:17 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/robot/javafx/scene/TextSurrogatePairInsertionIndexTest.java line 100: >> >>> 98: public static void initFX() { >>> 99: long seed = new Random().nextLong(); >>> 100: System.out.println("seed=" + seed); >> >> Do we need this print statement? > > yes. I've added a brief comment, but let me explain in more detail: > > these tests use random patterns to avoid hitting the same values each time. for example, in TextFlowSurrogatePairInsertionIndexTest many tests incremented the x coordinate by 5 prior to this change, but what if we had an error condition happening with x = 21?. the old test never hit that value, but the new one might (at some point). so we effectively extending the test coverage every time the test runs. > > and, if we ever encounter a failure, it will be possible to reproduce the exact failure scenario by setting the same seed as found in the failed log. Thanks for the details @andy-goryachev-oracle ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1154#discussion_r1233526756 From kpk at openjdk.org Mon Jun 19 05:06:16 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 19 Jun 2023 05:06:16 GMT Subject: RFR: 8302511: HitInfo.toString() throws IllegalArgumentException [v3] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 15:35:42 GMT, Andy Goryachev wrote: >> A recent change in JDK-8304831 ensured that insertionIndex is always computed prior to HitInfo construction, making it possible to remove buggy logic in HitInfo. This change also allows for removal of the 'text' field. >> >> There should be no impact since the constructor is package protected. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > whitespace Marked as reviewed by kpk (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1154#pullrequestreview-1485406067 From arapte at openjdk.org Mon Jun 19 12:54:22 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 19 Jun 2023 12:54:22 GMT Subject: RFR: 8304290: Some JNI calls made without checking exceptions in media [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 23:27:19 GMT, Alexander Matveev wrote: >> - Added missing exception checks for JNI calls. >> - Improved JNI error checking by checking for both exception and return value. >> - Minor code clean up. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8304290: Some JNI calls made without checking exceptions in media [v3] Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1094#pullrequestreview-1486165243 From Matija.Brown at outlook.de Mon Jun 19 19:14:52 2023 From: Matija.Brown at outlook.de (Matija Brown) Date: Mon, 19 Jun 2023 19:14:52 +0000 Subject: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Message-ID: On my never ending journey of building a Minecraft-clone in every graphics-framework available, I have come across JavaFX for the next attempt. However a minor inconvenience has crossed my path in the process: Using the (very well developed!) 2D-Graphics displaying pixel-art style images is no trouble whatsoever. Simply rendering it to a canvas and disabling smoothing does the job just fine. Unfortunately, I have been unable to figure out how to achieve a similar thing using the 3D-Graphics engine and the PhongMaterial that comes with it. Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? Unfortunately the latest information I could find online was from about 2013 and much has (probably) changed since then. Thus the question is being posed once again. I whish to excuse myself for probably repeating a fairly common question, Kind regards, Matija Brown. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvos at openjdk.org Mon Jun 19 20:06:29 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 19 Jun 2023 20:06:29 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v15] In-Reply-To: References: Message-ID: <5Dxr_y_E3T9D3GuOziRHe0jojbpWH_VDmGr0nKzTPm0=.ddf588cb-6461-48f9-80e0-6119744c4f70@github.com> On Tue, 13 Jun 2023 14:27:32 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: > > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - Revert format of timestamp in version OPT field > - Merge branch 'master' into allow-reproducible-builds > > Include two commits that fix WebKit build failures on Windows and macOS: > > 8282359: Intermittent WebKit build failure on Windows: > C1090: PDB API call failed, error code 23 > 8286089: Intermittent WebKit build failure on macOS in JavaScriptCore > - Merge branch 'master' into allow-reproducible-builds > - Support JDK 17 GA or later for building JavaFX > - Merge branch 'master' into allow-reproducible-builds > - Add '--date' argument for deterministic JMOD files > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - ... and 14 more: https://git.openjdk.org/jfx/compare/72be85ec...fd39e6d1 This is a good step towards 100% reproducible builds. I am slightly worried about the added complexity to the build.gradle but I don't see a real alternative. ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/446#pullrequestreview-1486864938 From duke at openjdk.org Mon Jun 19 22:12:15 2023 From: duke at openjdk.org (duke) Date: Mon, 19 Jun 2023 22:12:15 GMT Subject: Withdrawn: 8282886: Mouse event is generated outside of node on Raspberry Pi with Touchscreen In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 17:55:36 GMT, Alexander Scherbatiy wrote: > Tapping on a circle in the center of the screen sometimes generates mouse click events outside the circle with x coordinates set to zero. > > To reproduce the issue run the [JFXCircle](https://bugs.openjdk.java.net/secure/attachment/98241/JFXCircle.java) sample. > It has a circle in the center of the screen and a large rectangle under the circle which covers the whole screen. > Tap quickly 10 times on the circle. The output is: > > circle mouse pressed [416.000000, 199.000000]: 1 > circle mouse pressed [416.000000, 199.000000]: 2 > circle mouse pressed [419.000000, 196.000000]: 3 > circle mouse pressed [416.000000, 188.000000]: 4 > circle mouse pressed [419.000000, 190.000000]: 5 > rectangle mouse pressed [0.000000, 188.000000] > circle mouse pressed [422.000000, 185.000000]: 6 > circle mouse pressed [418.000000, 191.000000]: 7 > circle mouse pressed [417.000000, 187.000000]: 8 > circle mouse pressed [420.000000, 185.000000]: 9 > circle mouse pressed [416.000000, 187.000000]: 10 > circle mouse pressed [417.000000, 192.000000]: 11 > circle mouse pressed [420.000000, 188.000000]: 12 > > One mouse event is reported by the rectangle with zero x coordinate. > > The issue occurs when one of ABS_MT_POSITION_X or Y position is not reported. > For example, the output from `evtest /dev/input/event2` > > Event: time 1646845728.905383, -------------- SYN_REPORT ------------ > Event: time 1646845728.935382, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 1308 > Event: time 1646845728.935382, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 449 > Event: time 1646845728.935382, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 240 > Event: time 1646845728.935382, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1 > Event: time 1646845728.935382, type 3 (EV_ABS), code 0 (ABS_X), value 449 > Event: time 1646845728.935382, type 3 (EV_ABS), code 1 (ABS_Y), value 240 > Event: time 1646845728.935382, -------------- SYN_REPORT ------------ > Event: time 1646845729.025363, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 242 > Event: time 1646845729.025363, type 3 (EV_ABS), code 1 (ABS_Y), value 242 > Event: time 1646845729.025363, -------------- SYN_REPORT ------------ > Event: time 1646845729.055379, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1 > Event: time 1646845729.055379, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0 > Event: time 1646845729.055379, -------------- SYN_REPORT ------------ > > The first SYN_REPORT reports ABS_MT_POSITION_X/Y [449, 240] coordinates. > The second SYN_REPORT reports only ABS_MT_POSITION_Y value 2... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/749 From duke at openjdk.org Mon Jun 19 22:13:14 2023 From: duke at openjdk.org (duke) Date: Mon, 19 Jun 2023 22:13:14 GMT Subject: Withdrawn: 8282703: Axis is not cached in the LinuxTouchTransform class In-Reply-To: References: Message-ID: On Sat, 5 Mar 2022 15:53:52 GMT, Alexander Scherbatiy wrote: > An axis is not cached in the LinuxTouchTransform class. > > To reproduce the issue I added `System.out.printf("initTransform: axis: %d, index: %d%n", axis, index);` log to the LinuxTouchTransform.initTransform() method: > https://github.com/openjdk/jfx/blob/5112be957be70dd6521e6fb6ee64e669c148729c/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/LinuxTouchTransform.java#L117 > run the [JFXButtonExample](https://bugs.openjdk.java.net/secure/attachment/98181/JFXButtonExample.java) sample and tapped the touch screen on a Raspberry Pi with Touchscreen. > > The result was > > initTransform: axis: 47, index: 0 > initTransform: axis: 57, index: 0 > initTransform: axis: 53, index: 0 > initTransform: axis: 54, index: 0 > initTransform: axis: 0, index: 0 > initTransform: axis: 1, index: 0 > initTransform: axis: 53, index: 0 > initTransform: axis: 54, index: 0 > initTransform: axis: 0, index: 0 > initTransform: axis: 1, index: 0 > initTransform: axis: 53, index: 0 > initTransform: axis: 54, index: 0 > initTransform: axis: 0, index: 0 > initTransform: axis: 1, index: 0 > > The initTransform() is called several times for axis 0,1,47,53,54 and index is always set to zero. > > The straight forward fix is to store the given axis in the axes array: "axes[index] = axis". This is the first commit for the current fix. > Using this fix the output with printf from initTransform() method looks like: > > initTransform: axis: 47, index: 0 > initTransform: axis: 57, index: 1 > initTransform: axis: 53, index: 2 > initTransform: axis: 54, index: 4 > initTransform: axis: 1, index: 5 > > Now all axes are printed only once and the index value is different for each axes. > > However, the minimum/maximum values are retrieved and cached for ABS_X/Y and ABS_MT_POSITION_X/Y axes after the fist tap on the screen. > The second commit improves this moving the ABS_X/Y and ABS_MT_POSITION_X/Y axes initialization into the LinuxTouchTransform constructor. > > Now the touch logs look like: > > // LinuxTouchTransform constructor > // device: /dev/input/mouse0 > initTransform: axis: 0, index: 0 > initTransform: axis: 1, index: 1 > initTransform: axis: 53, index: 2 > initTransform: axis: 54, index: 3 > > // LinuxTouchTransform constructor > // device: /dev/input/event2 > initTransform: axis: 0, index: 0 > initTransform: axis: 1, index: 1 > initTransform: axis: 53, index: 2 > initTransform: axis: 54, index: 3 > > // the first tap > initTransform: axis: 57, index: 4 > initTransform: axis: 47, index: 5 > > > The ABS_X/Y and ABS_MT_POSITION_X/Y axes and corresponding minimum/maximum values are in... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/747 From duke at openjdk.org Mon Jun 19 22:14:15 2023 From: duke at openjdk.org (duke) Date: Mon, 19 Jun 2023 22:14:15 GMT Subject: Withdrawn: 8282104: Node zoom/rotate flickers on Raspberry Pi with Touchscreen In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 17:04:08 GMT, Alexander Scherbatiy wrote: > Zoomed/Rotated with two fingers rectangle flickers (unexpectedly becomes pretty small or large and then returns back to previous size several times during zooming/rotating) on a Raspberry Pi with Touchscreen. > > The log with traced events shows that it is possible that only one ABS_MT_POSITION_X or ABS_MT_POSITION_Y can be sent for a given slot. In this case the corresponding omitted Y/X value is undefined and is assigned from ABS_Y/X value. This produces incorrect result for slots different from 0. > > Example of the trace events log, enabled by `-Dmonocle.input.traceEvents.verbose=true -Dmonocle.input.traceEvents=true` flags: > > traceEvent: Processing EV_ABS ABS_MT_SLOT 1 [index=48] > traceEvent: Processing EV_ABS ABS_MT_TRACKING_ID 302 [index=64] > traceEvent: Processing EV_ABS ABS_MT_POSITION_X 399 [index=80] > traceEvent: Processing EV_ABS ABS_MT_POSITION_Y 272 [index=96] > traceEvent: Processing EV_KEY BTN_TOUCH 1 [index=112] > traceEvent: Read EV_ABS ABS_MT_SLOT 0 [index=176] > traceEvent: Read EV_ABS ABS_MT_POSITION_Y 315 [index=192] > traceEvent: Read EV_ABS ABS_Y 315 [index=208] > traceEvent: Read EV_SYN SYN_REPORT 0 [index=224] > > ... > > traceEvent: Read EV_ABS ABS_MT_SLOT 1 [index=320] > traceEvent: Read EV_ABS ABS_MT_POSITION_Y 271 [index=336] > traceEvent: Read EV_ABS ABS_X 552 [index=352] > traceEvent: Read EV_ABS ABS_Y 322 [index=368] > traceEvent: Read EV_SYN SYN_REPORT 0 [index=384] > > First both ABS_MT_POSITION_X/Y events with values x: 399 and y: 272 are received for the slot 1. > Next only ABS_MT_POSITION_Y with y: 271 value is received (which implies that the x value has not been changed) for the slot 1. > The x value is undefined in the LinuxStatefulMultiTouchProcessor.processEvents() loop and is unexpectedly assigned to the ABS_X 552 value which belongs to the slot 0. > > The fix skips setting ABS_X/Y values for slots different from 0. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/737 From jvos at openjdk.org Tue Jun 20 13:00:43 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 20 Jun 2023 13:00:43 GMT Subject: [jfx17u] RFR: 8301009: Update libxml2 to 2.10.3 Message-ID: 8301009: Update libxml2 to 2.10.3 Reviewed-by: kcr, sykora ------------- Commit messages: - 8301009: Update libxml2 to 2.10.3 Changes: https://git.openjdk.org/jfx17u/pull/132/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=132&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301009 Stats: 6301 lines in 80 files changed: 1128 ins; 4562 del; 611 mod Patch: https://git.openjdk.org/jfx17u/pull/132.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/132/head:pull/132 PR: https://git.openjdk.org/jfx17u/pull/132 From jpereda at openjdk.org Tue Jun 20 13:19:15 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 20 Jun 2023 13:19:15 GMT Subject: [jfx17u] RFR: 8301009: Update libxml2 to 2.10.3 In-Reply-To: References: Message-ID: On Tue, 20 Jun 2023 12:45:00 GMT, Johan Vos wrote: > 8301009: Update libxml2 to 2.10.3 > Reviewed-by: kcr, sykora Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/132#pullrequestreview-1488126879 From jvos at openjdk.org Tue Jun 20 13:19:16 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 20 Jun 2023 13:19:16 GMT Subject: [jfx17u] Integrated: 8301009: Update libxml2 to 2.10.3 In-Reply-To: References: Message-ID: On Tue, 20 Jun 2023 12:45:00 GMT, Johan Vos wrote: > 8301009: Update libxml2 to 2.10.3 > Reviewed-by: kcr, sykora This pull request has now been integrated. Changeset: aad7cb4a Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/aad7cb4aaf5638aac93482e38ff014e09515bc89 Stats: 6301 lines in 80 files changed: 1128 ins; 4562 del; 611 mod 8301009: Update libxml2 to 2.10.3 Reviewed-by: jpereda Backport-of: 935c7b797d79407d741735324313684617d1292d ------------- PR: https://git.openjdk.org/jfx17u/pull/132 From jvos at openjdk.org Tue Jun 20 13:31:13 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 20 Jun 2023 13:31:13 GMT Subject: [jfx17u] RFR: 8306115: Update libxml2 to 2.10.4 Message-ID: Clean backport of 8306115: Update libxml2 to 2.10.4 Reviewed-by: kcr, sykora ------------- Commit messages: - 8306115: Update libxml2 to 2.10.4 Changes: https://git.openjdk.org/jfx17u/pull/133/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=133&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306115 Stats: 95 lines in 12 files changed: 59 ins; 6 del; 30 mod Patch: https://git.openjdk.org/jfx17u/pull/133.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/133/head:pull/133 PR: https://git.openjdk.org/jfx17u/pull/133 From jvos at openjdk.org Tue Jun 20 13:32:16 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 20 Jun 2023 13:32:16 GMT Subject: [jfx11u] Integrated: 8301009: Update libxml2 to 2.10.3 Message-ID: Clean backport for 8301009: Update libxml2 to 2.10.3 Reviewed-by: kcr, sykora ------------- Commit messages: - 8301009: Update libxml2 to 2.10.3 Changes: https://git.openjdk.org/jfx11u/pull/140/files Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=140&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301009 Stats: 6301 lines in 80 files changed: 1128 ins; 4562 del; 611 mod Patch: https://git.openjdk.org/jfx11u/pull/140.diff Fetch: git fetch https://git.openjdk.org/jfx11u.git pull/140/head:pull/140 PR: https://git.openjdk.org/jfx11u/pull/140 From jpereda at openjdk.org Tue Jun 20 13:32:17 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 20 Jun 2023 13:32:17 GMT Subject: [jfx11u] Integrated: 8301009: Update libxml2 to 2.10.3 In-Reply-To: References: Message-ID: On Tue, 20 Jun 2023 13:18:18 GMT, Johan Vos wrote: > Clean backport for > 8301009: Update libxml2 to 2.10.3 > Reviewed-by: kcr, sykora Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx11u/pull/140#pullrequestreview-1488151311 From jvos at openjdk.org Tue Jun 20 13:32:18 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 20 Jun 2023 13:32:18 GMT Subject: [jfx11u] Integrated: 8301009: Update libxml2 to 2.10.3 In-Reply-To: References: Message-ID: On Tue, 20 Jun 2023 13:18:18 GMT, Johan Vos wrote: > Clean backport for > 8301009: Update libxml2 to 2.10.3 > Reviewed-by: kcr, sykora This pull request has now been integrated. Changeset: 86c84eec Author: Johan Vos URL: https://git.openjdk.org/jfx11u/commit/86c84eec7fe113efed987258a0bc6532c29b6fd6 Stats: 6301 lines in 80 files changed: 1128 ins; 4562 del; 611 mod 8301009: Update libxml2 to 2.10.3 Reviewed-by: jpereda Backport-of: 935c7b797d79407d741735324313684617d1292d ------------- PR: https://git.openjdk.org/jfx11u/pull/140 From jvos at openjdk.org Tue Jun 20 13:38:21 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 20 Jun 2023 13:38:21 GMT Subject: [jfx11u] RFR: 8306115: Update libxml2 to 2.10.4 Message-ID: 8306115: Update libxml2 to 2.10.4 Reviewed-by: kcr, sykora ------------- Commit messages: - 8306115: Update libxml2 to 2.10.4 Changes: https://git.openjdk.org/jfx11u/pull/141/files Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=141&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306115 Stats: 95 lines in 12 files changed: 59 ins; 6 del; 30 mod Patch: https://git.openjdk.org/jfx11u/pull/141.diff Fetch: git fetch https://git.openjdk.org/jfx11u.git pull/141/head:pull/141 PR: https://git.openjdk.org/jfx11u/pull/141 From jvos at openjdk.org Tue Jun 20 14:13:16 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 20 Jun 2023 14:13:16 GMT Subject: [jfx11u] Integrated: 8306115: Update libxml2 to 2.10.4 In-Reply-To: References: Message-ID: On Tue, 20 Jun 2023 13:31:52 GMT, Johan Vos wrote: > 8306115: Update libxml2 to 2.10.4 > Reviewed-by: kcr, sykora This pull request has now been integrated. Changeset: 4d3b3264 Author: Johan Vos URL: https://git.openjdk.org/jfx11u/commit/4d3b32649b25961730ddcc9d445b33da512b55cd Stats: 95 lines in 12 files changed: 59 ins; 6 del; 30 mod 8306115: Update libxml2 to 2.10.4 Backport-of: cf5b8389cd70d41a22d645added25a9978640e2c ------------- PR: https://git.openjdk.org/jfx11u/pull/141 From jvos at openjdk.org Tue Jun 20 14:14:13 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 20 Jun 2023 14:14:13 GMT Subject: [jfx17u] Integrated: 8306115: Update libxml2 to 2.10.4 In-Reply-To: References: Message-ID: On Tue, 20 Jun 2023 13:24:53 GMT, Johan Vos wrote: > Clean backport of > 8306115: Update libxml2 to 2.10.4 > Reviewed-by: kcr, sykora This pull request has now been integrated. Changeset: fa95c231 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/fa95c231f2069eeafc9ec3ae47b902c085d6cde7 Stats: 95 lines in 12 files changed: 59 ins; 6 del; 30 mod 8306115: Update libxml2 to 2.10.4 Backport-of: cf5b8389cd70d41a22d645added25a9978640e2c ------------- PR: https://git.openjdk.org/jfx17u/pull/133 From jgneff at openjdk.org Tue Jun 20 16:34:34 2023 From: jgneff at openjdk.org (John Neffenger) Date: Tue, 20 Jun 2023 16:34:34 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v15] In-Reply-To: References: Message-ID: On Tue, 13 Jun 2023 14:27:32 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: > > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - Revert format of timestamp in version OPT field > - Merge branch 'master' into allow-reproducible-builds > > Include two commits that fix WebKit build failures on Windows and macOS: > > 8282359: Intermittent WebKit build failure on Windows: > C1090: PDB API call failed, error code 23 > 8286089: Intermittent WebKit build failure on macOS in JavaScriptCore > - Merge branch 'master' into allow-reproducible-builds > - Support JDK 17 GA or later for building JavaFX > - Merge branch 'master' into allow-reproducible-builds > - Add '--date' argument for deterministic JMOD files > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - ... and 14 more: https://git.openjdk.org/jfx/compare/72be85ec...fd39e6d1 Please see all three of the following pull requests for a complete history of these changes: 1. [openjdk/jfx/99](https://github.com/openjdk/jfx/pull/99) - 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH (created 2020-01-29) 2. [openjdk/jfx/422](https://github.com/openjdk/jfx/pull/422) - 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH (created 2021-03-09) 3. [openjdk/jfx/446](https://github.com/openjdk/jfx/pull/446) - 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH (created 2021-03-30) ------------- PR Comment: https://git.openjdk.org/jfx/pull/446#issuecomment-1599128256 From jgneff at openjdk.org Tue Jun 20 16:45:32 2023 From: jgneff at openjdk.org (John Neffenger) Date: Tue, 20 Jun 2023 16:45:32 GMT Subject: Integrated: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 16:20:21 GMT, John Neffenger wrote: > This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: > > > $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) > $ bash gradlew sdk jmods javadoc > $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod > > > The three commands: > > 1. set the build timestamp to the date of the latest source code change, > 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and > 3. recreate the JMOD files with stable file modification times and ordering. > > The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. > > #### Fixes > > There are at least four sources of non-determinism in the JavaFX builds: > > 1. Build timestamp > > The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. > > 2. Modification times > > The JAR, JMOD, and ZIP archives store the modification time of each file. > > 3. File ordering > > The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. > > 4. Build path > > The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. > > This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism This pull request has now been integrated. Changeset: 0d9dcf38 Author: John Neffenger URL: https://git.openjdk.org/jfx/commit/0d9dcf38275528e1b621d71631aac5bdb9452110 Stats: 154 lines in 7 files changed: 123 ins; 13 del; 18 mod 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH Co-authored-by: Bernhard M. Wiedemann Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.org/jfx/pull/446 From nlisker at gmail.com Tue Jun 20 18:50:21 2023 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 20 Jun 2023 21:50:21 +0300 Subject: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In-Reply-To: References: Message-ID: > > Which leads to the question; Does there, in JavaFX exist something > comparable to setting the texture-sampler to NEAREST > > instead of LINEAR sampling? > There is no API to set the texture filter. If you would like to contribute and add it, I can help. It needs to be compatible with both Direct3D and OpenGL (not sure how the work on Metal is going), so this can be a challenge. For the D3D side, see this issue in JBS [1]. The relevant code is at [2]. I didn't look at the OpenGL side. - Nir [1] https://bugs.openjdk.org/browse/JDK-8092272 [2] https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc#L621 On Mon, Jun 19, 2023 at 10:15?PM Matija Brown wrote: > On my never ending journey of building a Minecraft-clone in every > graphics-framework available, > > I have come across JavaFX for the next attempt. > > > > > > However a minor inconvenience has crossed my path in the process: > > > > Using the (very well developed!) 2D-Graphics displaying pixel-art style > images is no trouble whatsoever. > > Simply rendering it to a canvas and disabling smoothing does the job just > fine. Unfortunately, I have been > > unable to figure out how to achieve a similar thing using the 3D-Graphics > engine and the PhongMaterial that comes with it. > > > > Which leads to the question; Does there, in JavaFX exist something > comparable to setting the texture-sampler to NEAREST > > instead of LINEAR sampling? > > Unfortunately the latest information I could find online was from about > 2013 and much has (probably) > > changed since then. Thus the question is being posed once again. > > > > > > I whish to excuse myself for probably repeating a fairly common question, > > > > Kind regards, > Matija Brown. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From almatvee at openjdk.org Tue Jun 20 21:01:20 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 20 Jun 2023 21:01:20 GMT Subject: Integrated: 8304290: Some JNI calls made without checking exceptions in media In-Reply-To: References: Message-ID: <-j0wDY3bb_o3NG9mLKAAj9P7YY33Sy3w-gQaPfD2AYA=.84b67458-0627-4fca-acd9-50e3f152c9a0@github.com> On Tue, 18 Apr 2023 02:08:03 GMT, Alexander Matveev wrote: > - Added missing exception checks for JNI calls. > - Improved JNI error checking by checking for both exception and return value. > - Minor code clean up. This pull request has now been integrated. Changeset: 77c43e0d Author: Alexander Matveev URL: https://git.openjdk.org/jfx/commit/77c43e0d7209da756a6b10bb29c88bd22f199f26 Stats: 291 lines in 15 files changed: 77 ins; 96 del; 118 mod 8304290: Some JNI calls made without checking exceptions in media Reviewed-by: arapte, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1094 From kpk at openjdk.org Wed Jun 21 06:39:28 2023 From: kpk at openjdk.org (Karthik P K) Date: Wed, 21 Jun 2023 06:39:28 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow Message-ID: The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when Text node was embedded in TextFlow. Hence wrong character index value was calculated for the same. Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index. Added tests to validate the changes. ------------- Commit messages: - Fix character index calculation issue in Text node embedded in TextFlow Changes: https://git.openjdk.org/jfx/pull/1157/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1157&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306083 Stats: 372 lines in 7 files changed: 358 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1157.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1157/head:pull/1157 PR: https://git.openjdk.org/jfx/pull/1157 From Matija.Brown at outlook.de Wed Jun 21 09:45:16 2023 From: Matija.Brown at outlook.de (Matija Brown) Date: Wed, 21 Jun 2023 09:45:16 +0000 Subject: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In-Reply-To: References: Message-ID: First of all, please excuse directly e-mailing you earlier today. Working with mailing lists is quite new for me and apparently I forgot to add the mailing list to cc. With the OpenGL-side I do have some experience. Concerning the D3D-side of things it would probably mean convincing Somebody that it is a good idea to finally apply the suggested change. There would be some API change required of course. As a basic concept it would probably be sensible to add this as a parameter to the PhonMaterial-class. Alternatively it might make sense to add a ?Texture? class that is used a a DiffuseMap in the PhonMaterial. But that seems slightly overkill. As I am not very well acquainted with current design principles of this library, these things should lie in more experience contributors hands. From: Nir Lisker Sent: Tuesday, 20 June 2023 20:50 To: Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? There is no API to set the texture filter. If you would like to contribute and add it, I can help. It needs to be compatible with both Direct3D and OpenGL (not sure how the work on Metal is going), so this can be a challenge. For the D3D side, see this issue in JBS [1]. The relevant code is at [2]. I didn't look at the OpenGL side. - Nir [1] https://bugs.openjdk.org/browse/JDK-8092272 [2] https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc#L621 On Mon, Jun 19, 2023 at 10:15?PM Matija Brown > wrote: On my never ending journey of building a Minecraft-clone in every graphics-framework available, I have come across JavaFX for the next attempt. However a minor inconvenience has crossed my path in the process: Using the (very well developed!) 2D-Graphics displaying pixel-art style images is no trouble whatsoever. Simply rendering it to a canvas and disabling smoothing does the job just fine. Unfortunately, I have been unable to figure out how to achieve a similar thing using the 3D-Graphics engine and the PhongMaterial that comes with it. Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? Unfortunately the latest information I could find online was from about 2013 and much has (probably) changed since then. Thus the question is being posed once again. I whish to excuse myself for probably repeating a fairly common question, Kind regards, Matija Brown. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Wed Jun 21 10:26:53 2023 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 21 Jun 2023 13:26:53 +0300 Subject: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In-Reply-To: References: Message-ID: > > First of all, please excuse directly e-mailing you earlier today. Working > with mailing lists is quite new for me and apparently I forgot to add > > the mailing list to cc. > I didn't get any private email, so you seem to be doing better than you thought with the mailing list :) > With the OpenGL-side I do have some experience. Concerning the D3D-side of > things it would probably mean convincing > > Somebody that it is a good idea to finally apply the suggested change. > > > > There would be some API change required of course. As a basic concept it > would probably be sensible to add this as a parameter to the > PhonMaterial-class. > > Alternatively it might make sense to add a ?Texture? class that is used a > a DiffuseMap in the PhonMaterial. But that seems slightly overkill. > Where to put the new methods in the Java side is not the concerning part, it's how to create methods that match all the pipelines. In D3D, the method for setting the filter is detailed in [1], and its possible parameters in [2][3][4]. So suppose that I'm looking at the list of available filter types there: D3DTEXF_NONE, D3DTEXF_POINT, D3DTEXF_LINEAR, D3DTEXF_ANISOTROPIC, D3DTEXF_PYRAMIDALQUAD, D3DTEXF_GAUSSIANQUAD, D3DTEXF_CONVOLUTIONMONO, if OpenGL supports a somewhat different set of filters, we will have some clashes in the Java API side. Generally, we would like to give as much flexibility to the user as possible, but need to be careful with platform-specific functionality. We could round *some* corners. For example, I think that if we have an enum for the filter types above that is a union of the ones available in the different pipelines, and if a few are supported by only one of the pipelines, we could note it in the docs and get away with it (something similar to a conditional feature). However, if the whole native pipeline setup for texture filtering is different, which means a different set of Java API methods per pipeline, then that's too much. All this means is that to continue we need to figure out what the API for each pipeline looks like, what's the most functionality we can have for each pipeline, and then how we can unite them into a single Java API with the hopes of being able to reconcile the differences "well enough" (whatever that will mean). [1] https://learn.microsoft.com/en-us/windows/win32/api/d3d9helper/nf-d3d9helper-idirect3ddevice9-setsamplerstate [2] https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dtexturefiltertype [3] https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dsamplerstatetype [4] https://learn.microsoft.com/en-us/windows/win32/direct3d9/vertex-textures-in-vs-3-0 On Wed, Jun 21, 2023 at 12:45?PM Matija Brown wrote: > First of all, please excuse directly e-mailing you earlier today. Working > with mailing lists is quite new for me and apparently I forgot to add > > the mailing list to cc. > > > > With the OpenGL-side I do have some experience. Concerning the D3D-side of > things it would probably mean convincing > > Somebody that it is a good idea to finally apply the suggested change. > > > > There would be some API change required of course. As a basic concept it > would probably be sensible to add this as a parameter to the > PhonMaterial-class. > > Alternatively it might make sense to add a ?Texture? class that is used a > a DiffuseMap in the PhonMaterial. But that seems slightly overkill. > > > > As I am not very well acquainted with current design principles of this > library, these things should lie in more experience contributors hands. > > > > *From: *Nir Lisker > *Sent: *Tuesday, 20 June 2023 20:50 > *To: *Matija Brown > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > > > Which leads to the question; Does there, in JavaFX exist something > comparable to setting the texture-sampler to NEAREST > > instead of LINEAR sampling? > > > > There is no API to set the texture filter. If you would like to contribute > and add it, I can help. It needs to be compatible with both Direct3D and > OpenGL (not sure how the work on Metal is going), so this can be a > challenge. > > > > For the D3D side, see this issue in JBS [1]. The relevant code is at [2]. > I didn't look at the OpenGL side. > > > > - Nir > > > > [1] https://bugs.openjdk.org/browse/JDK-8092272 > > [2] > https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc#L621 > > > > On Mon, Jun 19, 2023 at 10:15?PM Matija Brown > wrote: > > On my never ending journey of building a Minecraft-clone in every > graphics-framework available, > > I have come across JavaFX for the next attempt. > > > > > > However a minor inconvenience has crossed my path in the process: > > > > Using the (very well developed!) 2D-Graphics displaying pixel-art style > images is no trouble whatsoever. > > Simply rendering it to a canvas and disabling smoothing does the job just > fine. Unfortunately, I have been > > unable to figure out how to achieve a similar thing using the 3D-Graphics > engine and the PhongMaterial that comes with it. > > > > Which leads to the question; Does there, in JavaFX exist something > comparable to setting the texture-sampler to NEAREST > > instead of LINEAR sampling? > > Unfortunately the latest information I could find online was from about > 2013 and much has (probably) > > changed since then. Thus the question is being posed once again. > > > > > > I whish to excuse myself for probably repeating a fairly common question, > > > > Kind regards, > Matija Brown. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Jun 21 10:51:24 2023 From: duke at openjdk.org (Guillaume =?UTF-8?B?VMOiY2hl?=) Date: Wed, 21 Jun 2023 10:51:24 GMT Subject: RFR: 8260342: FXMLLoader fails to load a sub layout using fx:include with the resources attribute Message-ID: This fixes ResourceBundle loading by calling `ResourceBundle.getBundle(value, Locale.getDefault())` when the loader resources are null or their classloader is null. Apparently the original author of the bug report said they would submit a pull request, but it seems like it never happened. ------------- Commit messages: - 8260342: FXMLLoader fails to load a sub layout using fx:include with the resources attribute Changes: https://git.openjdk.org/jfx/pull/1158/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1158&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8260342 Stats: 208 lines in 8 files changed: 205 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1158.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1158/head:pull/1158 PR: https://git.openjdk.org/jfx/pull/1158 From jayathirth.d.v at oracle.com Wed Jun 21 11:09:25 2023 From: jayathirth.d.v at oracle.com (Jayathirth Rao Daarapuram Venkatesh Murthy) Date: Wed, 21 Jun 2023 11:09:25 +0000 Subject: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In-Reply-To: References: Message-ID: In OpenGL we set GL_LINEAR by default at : https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L221 And Metal supports only two types of Min/Max filters : Nearest(default) and Linear. So even if D3D supports multiple types we might be limited to support only these 2 filters for all platforms. Thanks, Jay From: openjfx-dev on behalf of Nir Lisker Date: Wednesday, 21 June 2023 at 3:57 PM To: Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial First of all, please excuse directly e-mailing you earlier today. Working with mailing lists is quite new for me and apparently I forgot to add the mailing list to cc. I didn't get any private email, so you seem to be doing better than you thought with the mailing list :) With the OpenGL-side I do have some experience. Concerning the D3D-side of things it would probably mean convincing Somebody that it is a good idea to finally apply the suggested change. There would be some API change required of course. As a basic concept it would probably be sensible to add this as a parameter to the PhonMaterial-class. Alternatively it might make sense to add a ?Texture? class that is used a a DiffuseMap in the PhonMaterial. But that seems slightly overkill. Where to put the new methods in the Java side is not the concerning part, it's how to create methods that match all the pipelines. In D3D, the method for setting the filter is detailed in [1], and its possible parameters in [2][3][4]. So suppose that I'm looking at the list of available filter types there: D3DTEXF_NONE, D3DTEXF_POINT, D3DTEXF_LINEAR, D3DTEXF_ANISOTROPIC, D3DTEXF_PYRAMIDALQUAD, D3DTEXF_GAUSSIANQUAD, D3DTEXF_CONVOLUTIONMONO, if OpenGL supports a somewhat different set of filters, we will have some clashes in the Java API side. Generally, we would like to give as much flexibility to the user as possible, but need to be careful with platform-specific functionality. We could round *some* corners. For example, I think that if we have an enum for the filter types above that is a union of the ones available in the different pipelines, and if a few are supported by only one of the pipelines, we could note it in the docs and get away with it (something similar to a conditional feature). However, if the whole native pipeline setup for texture filtering is different, which means a different set of Java API methods per pipeline, then that's too much. All this means is that to continue we need to figure out what the API for each pipeline looks like, what's the most functionality we can have for each pipeline, and then how we can unite them into a single Java API with the hopes of being able to reconcile the differences "well enough" (whatever that will mean). [1] https://learn.microsoft.com/en-us/windows/win32/api/d3d9helper/nf-d3d9helper-idirect3ddevice9-setsamplerstate [2] https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dtexturefiltertype [3] https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dsamplerstatetype [4] https://learn.microsoft.com/en-us/windows/win32/direct3d9/vertex-textures-in-vs-3-0 On Wed, Jun 21, 2023 at 12:45?PM Matija Brown > wrote: First of all, please excuse directly e-mailing you earlier today. Working with mailing lists is quite new for me and apparently I forgot to add the mailing list to cc. With the OpenGL-side I do have some experience. Concerning the D3D-side of things it would probably mean convincing Somebody that it is a good idea to finally apply the suggested change. There would be some API change required of course. As a basic concept it would probably be sensible to add this as a parameter to the PhonMaterial-class. Alternatively it might make sense to add a ?Texture? class that is used a a DiffuseMap in the PhonMaterial. But that seems slightly overkill. As I am not very well acquainted with current design principles of this library, these things should lie in more experience contributors hands. From: Nir Lisker Sent: Tuesday, 20 June 2023 20:50 To: Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? There is no API to set the texture filter. If you would like to contribute and add it, I can help. It needs to be compatible with both Direct3D and OpenGL (not sure how the work on Metal is going), so this can be a challenge. For the D3D side, see this issue in JBS [1]. The relevant code is at [2]. I didn't look at the OpenGL side. - Nir [1] https://bugs.openjdk.org/browse/JDK-8092272 [2] https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc#L621 On Mon, Jun 19, 2023 at 10:15?PM Matija Brown > wrote: On my never ending journey of building a Minecraft-clone in every graphics-framework available, I have come across JavaFX for the next attempt. However a minor inconvenience has crossed my path in the process: Using the (very well developed!) 2D-Graphics displaying pixel-art style images is no trouble whatsoever. Simply rendering it to a canvas and disabling smoothing does the job just fine. Unfortunately, I have been unable to figure out how to achieve a similar thing using the 3D-Graphics engine and the PhongMaterial that comes with it. Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? Unfortunately the latest information I could find online was from about 2013 and much has (probably) changed since then. Thus the question is being posed once again. I whish to excuse myself for probably repeating a fairly common question, Kind regards, Matija Brown. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matija.Brown at outlook.de Wed Jun 21 11:48:47 2023 From: Matija.Brown at outlook.de (Matija Brown) Date: Wed, 21 Jun 2023 11:48:47 +0000 Subject: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In-Reply-To: References: Message-ID: As Jayathrith said, in OpenGL as well as Metal only NEAREST and LINEAR filters are available. There might be a way of getting around it by implementing some own algorithm for OpenGL and Metal but that seem slightly over the top. So either one would have to keep the options limited to the two supported everywhere or go with the ?conditional? features. Having had a look at DirectX the APIs seem not to differ too much. If I remember correctly, in OpenGL you parse the texture filter when the texture is being created, while in DirectX as it is bound to the sampler (it is a sampler state after all) it would have to be set before every render call. However it shouldn?t make any API difference really, as we can just have a field somewhere and the parse it along when needed. Cheers, Matija. From: Jayathirth Rao Daarapuram Venkatesh Murthy Sent: Wednesday, 21 June 2023 13:09 To: Nir Lisker; Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In OpenGL we set GL_LINEAR by default at : https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L221 And Metal supports only two types of Min/Max filters : Nearest(default) and Linear. So even if D3D supports multiple types we might be limited to support only these 2 filters for all platforms. Thanks, Jay From: openjfx-dev on behalf of Nir Lisker Date: Wednesday, 21 June 2023 at 3:57 PM To: Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial First of all, please excuse directly e-mailing you earlier today. Working with mailing lists is quite new for me and apparently I forgot to add the mailing list to cc. I didn't get any private email, so you seem to be doing better than you thought with the mailing list :) With the OpenGL-side I do have some experience. Concerning the D3D-side of things it would probably mean convincing Somebody that it is a good idea to finally apply the suggested change. There would be some API change required of course. As a basic concept it would probably be sensible to add this as a parameter to the PhonMaterial-class. Alternatively it might make sense to add a ?Texture? class that is used a a DiffuseMap in the PhonMaterial. But that seems slightly overkill. Where to put the new methods in the Java side is not the concerning part, it's how to create methods that match all the pipelines. In D3D, the method for setting the filter is detailed in [1], and its possible parameters in [2][3][4]. So suppose that I'm looking at the list of available filter types there: D3DTEXF_NONE, D3DTEXF_POINT, D3DTEXF_LINEAR, D3DTEXF_ANISOTROPIC, D3DTEXF_PYRAMIDALQUAD, D3DTEXF_GAUSSIANQUAD, D3DTEXF_CONVOLUTIONMONO, if OpenGL supports a somewhat different set of filters, we will have some clashes in the Java API side. Generally, we would like to give as much flexibility to the user as possible, but need to be careful with platform-specific functionality. We could round *some* corners. For example, I think that if we have an enum for the filter types above that is a union of the ones available in the different pipelines, and if a few are supported by only one of the pipelines, we could note it in the docs and get away with it (something similar to a conditional feature). However, if the whole native pipeline setup for texture filtering is different, which means a different set of Java API methods per pipeline, then that's too much. All this means is that to continue we need to figure out what the API for each pipeline looks like, what's the most functionality we can have for each pipeline, and then how we can unite them into a single Java API with the hopes of being able to reconcile the differences "well enough" (whatever that will mean). [1] https://learn.microsoft.com/en-us/windows/win32/api/d3d9helper/nf-d3d9helper-idirect3ddevice9-setsamplerstate [2] https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dtexturefiltertype [3] https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dsamplerstatetype [4] https://learn.microsoft.com/en-us/windows/win32/direct3d9/vertex-textures-in-vs-3-0 On Wed, Jun 21, 2023 at 12:45?PM Matija Brown > wrote: First of all, please excuse directly e-mailing you earlier today. Working with mailing lists is quite new for me and apparently I forgot to add the mailing list to cc. With the OpenGL-side I do have some experience. Concerning the D3D-side of things it would probably mean convincing Somebody that it is a good idea to finally apply the suggested change. There would be some API change required of course. As a basic concept it would probably be sensible to add this as a parameter to the PhonMaterial-class. Alternatively it might make sense to add a ?Texture? class that is used a a DiffuseMap in the PhonMaterial. But that seems slightly overkill. As I am not very well acquainted with current design principles of this library, these things should lie in more experience contributors hands. From: Nir Lisker Sent: Tuesday, 20 June 2023 20:50 To: Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? There is no API to set the texture filter. If you would like to contribute and add it, I can help. It needs to be compatible with both Direct3D and OpenGL (not sure how the work on Metal is going), so this can be a challenge. For the D3D side, see this issue in JBS [1]. The relevant code is at [2]. I didn't look at the OpenGL side. - Nir [1] https://bugs.openjdk.org/browse/JDK-8092272 [2] https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc#L621 On Mon, Jun 19, 2023 at 10:15?PM Matija Brown > wrote: On my never ending journey of building a Minecraft-clone in every graphics-framework available, I have come across JavaFX for the next attempt. However a minor inconvenience has crossed my path in the process: Using the (very well developed!) 2D-Graphics displaying pixel-art style images is no trouble whatsoever. Simply rendering it to a canvas and disabling smoothing does the job just fine. Unfortunately, I have been unable to figure out how to achieve a similar thing using the 3D-Graphics engine and the PhongMaterial that comes with it. Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? Unfortunately the latest information I could find online was from about 2013 and much has (probably) changed since then. Thus the question is being posed once again. I whish to excuse myself for probably repeating a fairly common question, Kind regards, Matija Brown. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Wed Jun 21 12:58:13 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 21 Jun 2023 12:58:13 GMT Subject: RFR: 8260342: FXMLLoader fails to load a sub layout using fx:include with the resources attribute In-Reply-To: References: Message-ID: <-eQfcGNv91Z3JScvzxYLo3pgbysg4CRp6zE3BWIs3e4=.874b5bef-b257-4b09-98a8-7aba46365af0@github.com> On Wed, 21 Jun 2023 10:43:39 GMT, Guillaume T?che wrote: > This fixes ResourceBundle loading by calling `ResourceBundle.getBundle(value, Locale.getDefault())` when the loader resources are null or their classloader is null. > Apparently the original author of the bug report said they would submit a pull request, but it seems like it never happened. @gtache Please enable GitHub Actions workflows on your repo, and then push an empty commit to do a GHA run. @aghaisas Can you review this (including indicating whether you think it needs a second reviewer)? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1158#issuecomment-1600784203 From kevin.rushforth at oracle.com Wed Jun 21 13:03:06 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 21 Jun 2023 06:03:06 -0700 Subject: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In-Reply-To: References: Message-ID: My preference would be to add support only for Linear and Nearest in any case. -- Kevin On 6/21/2023 4:48 AM, Matija Brown wrote: > > As Jayathrith said, in OpenGL as well as Metal only NEAREST and LINEAR > filters are available. > > There might be a way of getting around it by implementing some own > algorithm for OpenGL and Metal but that seem slightly > > over the top. So either one would have to keep the options limited to > the two supported everywhere > > or go with the ?conditional? features. > > Having had a look at DirectX the APIs seem not to differ too much. > > If I remember correctly, in OpenGL you parse the texture filter when > the texture is being created, while in DirectX as it is bound > > to the sampler (it is a sampler state after all) it would have to be > set before every render call. However it shouldn?t make any > > API difference really, as we can just have a field somewhere and the > parse it along when needed. > > Cheers, > > Matija. > > *From: *Jayathirth Rao Daarapuram Venkatesh Murthy > > *Sent: *Wednesday, 21 June 2023 13:09 > *To: *Nir Lisker ; Matija Brown > > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > In OpenGL we set GL_LINEAR by default at : > https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L221 > > And Metal supports only two types of Min/Max filters : > Nearest(default) and Linear. So even if D3D supports multiple types we > might be limited to support only these 2 filters for all platforms. > > Thanks, > > Jay > > *From: *openjfx-dev on behalf of Nir > Lisker > *Date: *Wednesday, 21 June 2023 at 3:57 PM > *To: *Matija Brown > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > First of all, please excuse directly e-mailing you earlier today. > Working with mailing lists is quite new for me and apparently I > forgot to add > > the mailing list to cc. > > I didn't get any private email, so you seem to be doing better than > you thought with the mailing list :) > > With the OpenGL-side I do have some experience. Concerning the > D3D-side of things it would probably mean convincing > > Somebody that it is a good idea to finally apply the suggested change. > > There would be some API change required of course. As a basic > concept it would probably be sensible to add this as a parameter > to the PhonMaterial-class. > > Alternatively it might make sense to add a ?Texture? class that is > used a a DiffuseMap in the PhonMaterial. But that seems slightly > overkill. > > Where to put the new methods in the Java side is not the > concerning?part, it's how to create methods that match all > the?pipelines. In D3D, the method for setting the filter is detailed > in [1], and its possible parameters in [2][3][4]. So suppose that I'm > looking at the list of available filter types there: > > D3DTEXF_NONE, D3DTEXF_POINT, D3DTEXF_LINEAR, D3DTEXF_ANISOTROPIC, > D3DTEXF_PYRAMIDALQUAD, D3DTEXF_GAUSSIANQUAD, D3DTEXF_CONVOLUTIONMONO, > > if OpenGL supports a somewhat different set of filters, we will have > some clashes in the Java API side. > > Generally, we would like to give as much flexibility to the user as > possible, but need to be careful with?platform-specific functionality. > We could round *some* corners. For example, I think that if we have an > enum for the filter types above that is a union of the ones available > in the different pipelines, and if a few are supported by only one of > the pipelines, we could note it in the docs and get away with it > (something similar to a conditional feature). However, if the whole > native pipeline setup for texture filtering is different, which means > a different set of Java API methods per pipeline, then that's too much. > > All this means is that to continue we need to figure out what the API > for each pipeline looks like, what's the most functionality we can > have for each pipeline, and then how we can unite them into a single > Java API with the hopes of being able to reconcile the differences > "well?enough" (whatever that will mean). > > [1] > https://learn.microsoft.com/en-us/windows/win32/api/d3d9helper/nf-d3d9helper-idirect3ddevice9-setsamplerstate > > [2] > https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dtexturefiltertype > > [3] > https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dsamplerstatetype > > [4] > https://learn.microsoft.com/en-us/windows/win32/direct3d9/vertex-textures-in-vs-3-0 > > On Wed, Jun 21, 2023 at 12:45?PM Matija Brown > wrote: > > First of all, please excuse directly e-mailing you earlier today. > Working with mailing lists is quite new for me and apparently I > forgot to add > > the mailing list to cc. > > With the OpenGL-side I do have some experience. Concerning the > D3D-side of things it would probably mean convincing > > Somebody that it is a good idea to finally apply the suggested change. > > There would be some API change required of course. As a basic > concept it would probably be sensible to add this as a parameter > to the PhonMaterial-class. > > Alternatively it might make sense to add a ?Texture? class that is > used a a DiffuseMap in the PhonMaterial. But that seems slightly > overkill. > > As I am not very well acquainted with current design principles of > this library, these things should lie in more experience > contributors hands. > > *From: *Nir Lisker > *Sent: *Tuesday, 20 June 2023 20:50 > *To: *Matija Brown > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > Which leads to the question; Does there, in JavaFX exist > something comparable to setting the texture-sampler to NEAREST > > instead of LINEAR sampling? > > There is no API to set the texture filter. If you would like to > contribute and add it, I can help. It needs to be compatible with > both Direct3D and OpenGL (not sure how the work on Metal is > going), so this can be a challenge. > > For the?D3D side, see this issue in JBS [1]. The relevant code is > at [2]. I didn't look at the OpenGL side. > > - Nir > > [1] https://bugs.openjdk.org/browse/JDK-8092272 > > [2] > https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc#L621 > > On Mon, Jun 19, 2023 at 10:15?PM Matija Brown > wrote: > > On my never ending journey of building a Minecraft-clone in > every graphics-framework available, > > I have come across JavaFX for the next attempt. > > However a minor inconvenience has crossed my path in the process: > > Using the (very well developed!) 2D-Graphics displaying > pixel-art style images is no trouble whatsoever. > > Simply rendering it to a canvas and disabling smoothing does > the job just fine. Unfortunately, I have been > > unable to figure out how to achieve a similar thing using the > 3D-Graphics engine and the PhongMaterial that comes with it. > > Which leads to the question; Does there, in JavaFX exist > something comparable to setting the texture-sampler to NEAREST > > instead of LINEAR sampling? > > Unfortunately the latest information I could find online was > from about 2013 and much has (probably) > > changed since then. Thus the question is being posed once again. > > I whish to excuse myself for probably repeating a fairly > common question, > > Kind regards, > Matija Brown. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Jun 21 13:34:28 2023 From: duke at openjdk.org (Guillaume =?UTF-8?B?VMOiY2hl?=) Date: Wed, 21 Jun 2023 13:34:28 GMT Subject: RFR: 8260342: FXMLLoader fails to load a sub layout using fx:include with the resources attribute [v2] In-Reply-To: References: Message-ID: > This fixes ResourceBundle loading by calling `ResourceBundle.getBundle(value, Locale.getDefault())` when the loader resources are null or their classloader is null. > Apparently the original author of the bug report said they would submit a pull request, but it seems like it never happened. Guillaume T?che has updated the pull request incrementally with one additional commit since the last revision: Empty commit ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1158/files - new: https://git.openjdk.org/jfx/pull/1158/files/420e6501..92da990d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1158&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1158&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1158.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1158/head:pull/1158 PR: https://git.openjdk.org/jfx/pull/1158 From kcr at openjdk.org Wed Jun 21 15:22:00 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 21 Jun 2023 15:22:00 GMT Subject: RFR: 8180066: Convert package.html files to package-info.java Message-ID: This is a doc cleanup task to convert all `package.html` files to `package-info.java`, which is the recommended way to provide package documentation. The first commit is the result of running a shell script that @jonathan-gibbons provided. The second commit removes an errant `

    ` tag from the `package-info.java` for one package, `javafx.util.converter` that is unneeded and unwanted. That same file also had a redundant first sentence, which was coincidentally removed by the tool, so once I removed the `

    ` tag the docs for that package now looks good and matches the other packages. There are no other changes in the javadoc-generated API docs. One thing I didn't do is add a ` *` at the beginning of the lines that are now part of a javadoc-style comment block. This minimizes the diffs, but it means we won't be using the usual pattern for those comment blocks. I'm inclined to file a follow-up issue rather than changing that now. ------------- Commit messages: - Fix whitespace - Remove erroneous

    tag - 8180066: Convert package.html files to package-info.java Changes: https://git.openjdk.org/jfx/pull/1159/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1159&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8180066 Stats: 2982 lines in 68 files changed: 1289 ins; 1649 del; 44 mod Patch: https://git.openjdk.org/jfx/pull/1159.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1159/head:pull/1159 PR: https://git.openjdk.org/jfx/pull/1159 From arapte at openjdk.org Wed Jun 21 16:07:13 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 21 Jun 2023 16:07:13 GMT Subject: RFR: 8299348: Size-restricted window can be observed with incorrect dimensions [v2] In-Reply-To: References: <9zNyOtonYujDxiJZQQs_Xtx8ewS63NLff04eebFzEWU=.8ddb924d-d8cd-49bb-a61e-ec2c447c9ad0@github.com> Message-ID: <5KLYvkOL6CKxyUk3MiZsW_GOuNv4yaY82WFIw2oqLQU=.4fdeb593-2a67-46f4-ba15-ce52b7597b8d@github.com> On Sat, 13 May 2023 17:22:53 GMT, Michael Strau? wrote: >> On Windows, a `Stage` that is restricted by minimum and maximum sizes can briefly be observed to appear with incorrect dimensions when it is first shown. The root cause of this bug is that the native `WinWindow._setBounds` method doesn't respect min/max sizes when calculating the window rect. >> >> Note to reviewers: I've removed the unused `GlassWindow::updateMinMaxSize` method as to not confuse readers where min-max handling actually happens. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments LGTM too ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/984#pullrequestreview-1491158468 From nlisker at gmail.com Wed Jun 21 16:09:44 2023 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 21 Jun 2023 19:09:44 +0300 Subject: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In-Reply-To: References: Message-ID: > > If I remember correctly, in OpenGL you parse the texture filter when the > texture is being created, while in DirectX as it is bound > > to the sampler (it is a sampler state after all) it would have to be set > before every render call. However it shouldn?t make any > > API difference really, as we can just have a field somewhere and the parse > it along when needed. > Yes, the JBS ticket mentions this difference as well. Since Kevin approved this feature and the API seems to converge nicely between the pipelines, we can start the work. I'm somewhat busy with other tasks as of late, but I will try to formulate an API. Matija or Jay, if one of you can start investigating the changes to the OpenGL pipeline we could create a branch in the sandbox repo and work there. On Wed, Jun 21, 2023 at 4:03?PM Kevin Rushforth wrote: > My preference would be to add support only for Linear and Nearest in any > case. > > -- Kevin > > > On 6/21/2023 4:48 AM, Matija Brown wrote: > > As Jayathrith said, in OpenGL as well as Metal only NEAREST and LINEAR > filters are available. > > > > There might be a way of getting around it by implementing some own > algorithm for OpenGL and Metal but that seem slightly > > over the top. So either one would have to keep the options limited to the > two supported everywhere > > or go with the ?conditional? features. > > > > Having had a look at DirectX the APIs seem not to differ too much. > > If I remember correctly, in OpenGL you parse the texture filter when the > texture is being created, while in DirectX as it is bound > > to the sampler (it is a sampler state after all) it would have to be set > before every render call. However it shouldn?t make any > > API difference really, as we can just have a field somewhere and the parse > it along when needed. > > > > Cheers, > > Matija. > > > > *From: *Jayathirth Rao Daarapuram Venkatesh Murthy > > *Sent: *Wednesday, 21 June 2023 13:09 > *To: *Nir Lisker ; Matija Brown > > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > > > In OpenGL we set GL_LINEAR by default at : > https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L221 > > > > And Metal supports only two types of Min/Max filters : Nearest(default) > and Linear. So even if D3D supports multiple types we might be limited to > support only these 2 filters for all platforms. > > > > Thanks, > > Jay > > > > *From: *openjfx-dev > on behalf of Nir Lisker > > *Date: *Wednesday, 21 June 2023 at 3:57 PM > *To: *Matija Brown > *Cc: *openjfx-dev at openjdk.org > > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > First of all, please excuse directly e-mailing you earlier today. Working > with mailing lists is quite new for me and apparently I forgot to add > > the mailing list to cc. > > > > I didn't get any private email, so you seem to be doing better than you > thought with the mailing list :) > > > > With the OpenGL-side I do have some experience. Concerning the D3D-side of > things it would probably mean convincing > > Somebody that it is a good idea to finally apply the suggested change. > > > > There would be some API change required of course. As a basic concept it > would probably be sensible to add this as a parameter to the > PhonMaterial-class. > > Alternatively it might make sense to add a ?Texture? class that is used a > a DiffuseMap in the PhonMaterial. But that seems slightly overkill. > > > > Where to put the new methods in the Java side is not the concerning part, > it's how to create methods that match all the pipelines. In D3D, the method > for setting the filter is detailed in [1], and its possible parameters in > [2][3][4]. So suppose that I'm looking at the list of available filter > types there: > > D3DTEXF_NONE, D3DTEXF_POINT, D3DTEXF_LINEAR, D3DTEXF_ANISOTROPIC, > D3DTEXF_PYRAMIDALQUAD, D3DTEXF_GAUSSIANQUAD, D3DTEXF_CONVOLUTIONMONO, > > if OpenGL supports a somewhat different set of filters, we will have some > clashes in the Java API side. > > > > Generally, we would like to give as much flexibility to the user as > possible, but need to be careful with platform-specific functionality. We > could round *some* corners. For example, I think that if we have an enum > for the filter types above that is a union of the ones available in the > different pipelines, and if a few are supported by only one of the > pipelines, we could note it in the docs and get away with it (something > similar to a conditional feature). However, if the whole native pipeline > setup for texture filtering is different, which means a different set of > Java API methods per pipeline, then that's too much. > > > > All this means is that to continue we need to figure out what the API for > each pipeline looks like, what's the most functionality we can have for > each pipeline, and then how we can unite them into a single Java API with > the hopes of being able to reconcile the differences "well enough" > (whatever that will mean). > > > > [1] > https://learn.microsoft.com/en-us/windows/win32/api/d3d9helper/nf-d3d9helper-idirect3ddevice9-setsamplerstate > > [2] > https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dtexturefiltertype > > [3] > https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dsamplerstatetype > > [4] > https://learn.microsoft.com/en-us/windows/win32/direct3d9/vertex-textures-in-vs-3-0 > > > > On Wed, Jun 21, 2023 at 12:45?PM Matija Brown > wrote: > > First of all, please excuse directly e-mailing you earlier today. Working > with mailing lists is quite new for me and apparently I forgot to add > > the mailing list to cc. > > > > With the OpenGL-side I do have some experience. Concerning the D3D-side of > things it would probably mean convincing > > Somebody that it is a good idea to finally apply the suggested change. > > > > There would be some API change required of course. As a basic concept it > would probably be sensible to add this as a parameter to the > PhonMaterial-class. > > Alternatively it might make sense to add a ?Texture? class that is used a > a DiffuseMap in the PhonMaterial. But that seems slightly overkill. > > > > As I am not very well acquainted with current design principles of this > library, these things should lie in more experience contributors hands. > > > > *From: *Nir Lisker > *Sent: *Tuesday, 20 June 2023 20:50 > *To: *Matija Brown > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > > > Which leads to the question; Does there, in JavaFX exist something > comparable to setting the texture-sampler to NEAREST > > instead of LINEAR sampling? > > > > There is no API to set the texture filter. If you would like to contribute > and add it, I can help. It needs to be compatible with both Direct3D and > OpenGL (not sure how the work on Metal is going), so this can be a > challenge. > > > > For the D3D side, see this issue in JBS [1]. The relevant code is at [2]. > I didn't look at the OpenGL side. > > > > - Nir > > > > [1] https://bugs.openjdk.org/browse/JDK-8092272 > > [2] > https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc#L621 > > > > On Mon, Jun 19, 2023 at 10:15?PM Matija Brown > wrote: > > On my never ending journey of building a Minecraft-clone in every > graphics-framework available, > > I have come across JavaFX for the next attempt. > > > > > > However a minor inconvenience has crossed my path in the process: > > > > Using the (very well developed!) 2D-Graphics displaying pixel-art style > images is no trouble whatsoever. > > Simply rendering it to a canvas and disabling smoothing does the job just > fine. Unfortunately, I have been > > unable to figure out how to achieve a similar thing using the 3D-Graphics > engine and the PhongMaterial that comes with it. > > > > Which leads to the question; Does there, in JavaFX exist something > comparable to setting the texture-sampler to NEAREST > > instead of LINEAR sampling? > > Unfortunately the latest information I could find online was from about > 2013 and much has (probably) > > changed since then. Thus the question is being posed once again. > > > > > > I whish to excuse myself for probably repeating a fairly common question, > > > > Kind regards, > Matija Brown. > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Wed Jun 21 16:13:16 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 21 Jun 2023 16:13:16 GMT Subject: Integrated: 8299348: Size-restricted window can be observed with incorrect dimensions In-Reply-To: <9zNyOtonYujDxiJZQQs_Xtx8ewS63NLff04eebFzEWU=.8ddb924d-d8cd-49bb-a61e-ec2c447c9ad0@github.com> References: <9zNyOtonYujDxiJZQQs_Xtx8ewS63NLff04eebFzEWU=.8ddb924d-d8cd-49bb-a61e-ec2c447c9ad0@github.com> Message-ID: On Mon, 26 Dec 2022 03:03:50 GMT, Michael Strau? wrote: > On Windows, a `Stage` that is restricted by minimum and maximum sizes can briefly be observed to appear with incorrect dimensions when it is first shown. The root cause of this bug is that the native `WinWindow._setBounds` method doesn't respect min/max sizes when calculating the window rect. > > Note to reviewers: I've removed the unused `GlassWindow::updateMinMaxSize` method as to not confuse readers where min-max handling actually happens. This pull request has now been integrated. Changeset: a17a7145 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/a17a71458def91d206844b7d64e185af75a3c6e0 Stats: 117 lines in 3 files changed: 90 ins; 25 del; 2 mod 8299348: Size-restricted window can be observed with incorrect dimensions Reviewed-by: jhendrikx, mhanl, arapte ------------- PR: https://git.openjdk.org/jfx/pull/984 From angorya at openjdk.org Wed Jun 21 18:40:08 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 21 Jun 2023 18:40:08 GMT Subject: RFR: 8180066: Convert package.html files to package-info.java In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 15:05:47 GMT, Kevin Rushforth wrote: > This is a doc cleanup task to convert all `package.html` files to `package-info.java`, which is the recommended way to provide package documentation. > > The first commit is the result of running a shell script that @jonathan-gibbons provided. The second commit removes an errant `

    ` tag from the `package-info.java` for one package, `javafx.util.converter` that is unneeded and unwanted. That same file also had a redundant first sentence, which was coincidentally removed by the tool, so once I removed the `

    ` tag the docs for that package now looks good and matches the other packages. There are no other changes in the javadoc-generated API docs. > > One thing I didn't do is add a ` *` at the beginning of the lines that are now part of a javadoc-style comment block. This minimizes the diffs, but it means we won't be using the usual pattern for those comment blocks. I'm inclined to file a follow-up issue rather than changing that now. String converters link got lost in allpackages-index and index-all. is this intentional? Screenshot 2023-06-21 at 11 34 39 also in javafx.base/module-summary.html javafx.base/javafx/beans/class-use/NamedArg.html javafx.base/javafx/beans/package-use.html ------------- PR Comment: https://git.openjdk.org/jfx/pull/1159#issuecomment-1601380303 From angorya at openjdk.org Wed Jun 21 18:46:13 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 21 Jun 2023 18:46:13 GMT Subject: RFR: 8180066: Convert package.html files to package-info.java In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 15:05:47 GMT, Kevin Rushforth wrote: > This is a doc cleanup task to convert all `package.html` files to `package-info.java`, which is the recommended way to provide package documentation. > > The first commit is the result of running a shell script that @jonathan-gibbons provided. The second commit removes an errant `

    ` tag from the `package-info.java` for one package, `javafx.util.converter` that is unneeded and unwanted. That same file also had a redundant first sentence, which was coincidentally removed by the tool, so once I removed the `

    ` tag the docs for that package now looks good and matches the other packages. There are no other changes in the javadoc-generated API docs. > > One thing I didn't do is add a ` *` at the beginning of the lines that are now part of a javadoc-style comment block. This minimizes the diffs, but it means we won't be using the usual pattern for those comment blocks. I'm inclined to file a follow-up issue rather than changing that now. The rest of diff are not important as they all contain whitespace changes that are normally ignored by the browser. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1159#issuecomment-1601388740 From angorya at openjdk.org Wed Jun 21 18:57:09 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 21 Jun 2023 18:57:09 GMT Subject: RFR: 8180066: Convert package.html files to package-info.java In-Reply-To: References: Message-ID: <4lZFJzGjErZD8cPv3rq7QO_MhGgtONhge-C0XVCS26o=.6fd2f8d1-7297-4021-ad50-a351764e140e@github.com> On Wed, 21 Jun 2023 15:05:47 GMT, Kevin Rushforth wrote: > This is a doc cleanup task to convert all `package.html` files to `package-info.java`, which is the recommended way to provide package documentation. > > The first commit is the result of running a shell script that @jonathan-gibbons provided. The second commit removes an errant `

    ` tag from the `package-info.java` for one package, `javafx.util.converter` that is unneeded and unwanted. That same file also had a redundant first sentence, which was coincidentally removed by the tool, so once I removed the `

    ` tag the docs for that package now looks good and matches the other packages. There are no other changes in the javadoc-generated API docs. > > One thing I didn't do is add a ` *` at the beginning of the lines that are now part of a javadoc-style comment block. This minimizes the diffs, but it means we won't be using the usual pattern for those comment blocks. I'm inclined to file a follow-up issue rather than changing that now. Looking good. I guess we don't change the copyright year because we don't change the actual content? Or should it be changed? right, got my diff panels swapped. so all the non-whitespace diffs have newfound link, we are good! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1159#pullrequestreview-1491489377 PR Comment: https://git.openjdk.org/jfx/pull/1159#issuecomment-1601408205 From kcr at openjdk.org Wed Jun 21 18:57:11 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 21 Jun 2023 18:57:11 GMT Subject: RFR: 8180066: Convert package.html files to package-info.java In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 18:35:50 GMT, Andy Goryachev wrote: > String converters link got lost in allpackages-index and index-all. is this intentional? It's the other way around. That link is _not_ present in the existing JavaFX API docs because of the redundant first sentence. It is now there because I got rid of the redundant first sentence (the one without the link) and the unwanted `

    ` tag, making the following the first sentence: This package is for standard {@link javafx.util.StringConverter string converters} for JavaFX. So the link wasn't lost, it was found. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1159#issuecomment-1601403187 From kcr at openjdk.org Wed Jun 21 18:57:12 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 21 Jun 2023 18:57:12 GMT Subject: RFR: 8180066: Convert package.html files to package-info.java In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 15:05:47 GMT, Kevin Rushforth wrote: > This is a doc cleanup task to convert all `package.html` files to `package-info.java`, which is the recommended way to provide package documentation. > > The first commit is the result of running a shell script that @jonathan-gibbons provided. The second commit removes an errant `

    ` tag from the `package-info.java` for one package, `javafx.util.converter` that is unneeded and unwanted. That same file also had a redundant first sentence, which was coincidentally removed by the tool, so once I removed the `

    ` tag the docs for that package now looks good and matches the other packages. There are no other changes in the javadoc-generated API docs. > > One thing I didn't do is add a ` *` at the beginning of the lines that are now part of a javadoc-style comment block. This minimizes the diffs, but it means we won't be using the usual pattern for those comment blocks. I'm inclined to file a follow-up issue rather than changing that now. Unfortunately, with all of the whitespace diffs, it's now hard to see the actual changes. It might be worth looking at the diffs from the first two commits, and then separately confirming that the third commit is just whitespace changes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1159#issuecomment-1601405789 From kcr at openjdk.org Wed Jun 21 19:44:08 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 21 Jun 2023 19:44:08 GMT Subject: RFR: 8180066: Convert package.html files to package-info.java In-Reply-To: <4lZFJzGjErZD8cPv3rq7QO_MhGgtONhge-C0XVCS26o=.6fd2f8d1-7297-4021-ad50-a351764e140e@github.com> References: <4lZFJzGjErZD8cPv3rq7QO_MhGgtONhge-C0XVCS26o=.6fd2f8d1-7297-4021-ad50-a351764e140e@github.com> Message-ID: On Wed, 21 Jun 2023 18:54:40 GMT, Andy Goryachev wrote: > I guess we don't change the copyright year because we don't change the actual content? Or should it be changed? Right. Even if we did want to change it, I would just let our copyright scripts update it, rather than doing it manually (which is somewhat error-prone), but in this case, we'll exclude this commit when running the tool, so we will skip the copyright year update altogether. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1159#issuecomment-1601569775 From angorya at openjdk.org Wed Jun 21 23:02:12 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 21 Jun 2023 23:02:12 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 06:34:00 GMT, Karthik P K wrote: > The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when Text node was embedded in TextFlow. Hence wrong character index value was calculated for the same. > > Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index. > > Added tests to validate the changes. Looks like Text.hitTest() does not return the right information (charIndex=0, leading) for text on either the second line, or a wrapped line. (mouse over over 2nd/3rd lines): ![Screenshot 2023-06-21 at 15 56 30](https://github.com/openjdk/jfx/assets/107069028/19ed50e0-453d-4aea-8683-ef1e1ff95e64) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1601798335 From mstrauss at openjdk.org Thu Jun 22 03:10:09 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 22 Jun 2023 03:10:09 GMT Subject: RFR: 8283551: ControlAcceleratorSupport menu items listener causes memory leak [v2] In-Reply-To: References: Message-ID: <6hA2yesZpkUzxbWtdEPxyVA-3mgvslJLzUE-k8U0JVE=.c54c48d1-bb59-422d-89d7-5b5f2b1cc169@github.com> On Fri, 24 Feb 2023 10:04:48 GMT, Dean Wookey wrote: >> Each time a menu would change scenes, a new set of ListChangeListeners would be added to the items in the menu. The bigger problem however is that these list change listeners have a strong reference to the scene which is potentially a much bigger leak. >> >> The first commit was more straightforward, but there are 2 things that might be of concern: >> >> 1. The method removeAcceleratorsFromScene takes in a scene parameter, but it'll remove all the ListChangeListeners attached to it, regardless of which scene was passed in. Something similar happens with changeListenerMap already, so I think it's fine. >> 2. I made the remove method public so that external calls from skins to remove the accelerators would remove the ListChangeListener and also because all the remove methods are public. >> >> After I wrote more tests I realised using the ObservableLists as keys in the WeakHashMaps was a bad idea. If Java had a WeakIdentityHashMap the fix would be simple. The fix is in the second commit. >> >> There are still more issues that stem from the fact that for each anchor there could be multiple menus and the current code doesn't account for that. For example, swapping context menus on a tab doesn't register change listeners on the new context menu because the TabPane itself had a scene change listener already. These other issues could relate to JDK-8268374 https://bugs.openjdk.org/browse/JDK-8268374 and JDK-8283449 https://bugs.openjdk.org/browse/JDK-8283449. One of the issues is related to the fact that there's no logic to remove listeners when Tab/TableColumn's are removed from their associated control (TabPane, TableView, TreeTableView). >> >> I'm looking at these issues, but I think they're dependent on this fix. Either I can add to this PR or I can wait to see what comes out of this and fix them subsequently. > > Dean Wookey has updated the pull request incrementally with one additional commit since the last revision: > > Added more comments and fixed IdentityWrapper hashcode. `ControlAcceleratorSupport` is a strange beast. There's tons of manual book-keeping, global static maps (unsynchronized, which may or may not be a problem), weak references, all of that basically to do just one thing: add an accelerator to a `Scene`, and remove it after it's no longer needed. I wonder if this really is the best we can do here. (Maybe it is.) Approving the fix, but I suggest that we investigate if there's a simpler way to achieve the same thing. ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1037#pullrequestreview-1492275398 From jayathirth.d.v at oracle.com Thu Jun 22 03:51:45 2023 From: jayathirth.d.v at oracle.com (Jayathirth Rao Daarapuram Venkatesh Murthy) Date: Thu, 22 Jun 2023 03:51:45 +0000 Subject: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In-Reply-To: References: Message-ID: Currently I am working on Metal implementation of the same and has no bandwidth to work on additional OpenGL thing. But I can help in reviewing the code if we come up with addition of nearest filtering. Thanks, Jay From: openjfx-dev on behalf of Nir Lisker Date: Wednesday, 21 June 2023 at 9:40 PM To: Kevin Rushforth Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial If I remember correctly, in OpenGL you parse the texture filter when the texture is being created, while in DirectX as it is bound to the sampler (it is a sampler state after all) it would have to be set before every render call. However it shouldn?t make any API difference really, as we can just have a field somewhere and the parse it along when needed. Yes, the JBS ticket mentions this difference as well. Since Kevin approved this feature and the API seems to converge nicely between the pipelines, we can start the work. I'm somewhat busy with other tasks as of late, but I will try to formulate an API. Matija or Jay, if one of you can start investigating the changes to the OpenGL pipeline we could create a branch in the sandbox repo and work there. On Wed, Jun 21, 2023 at 4:03?PM Kevin Rushforth > wrote: My preference would be to add support only for Linear and Nearest in any case. -- Kevin On 6/21/2023 4:48 AM, Matija Brown wrote: As Jayathrith said, in OpenGL as well as Metal only NEAREST and LINEAR filters are available. There might be a way of getting around it by implementing some own algorithm for OpenGL and Metal but that seem slightly over the top. So either one would have to keep the options limited to the two supported everywhere or go with the ?conditional? features. Having had a look at DirectX the APIs seem not to differ too much. If I remember correctly, in OpenGL you parse the texture filter when the texture is being created, while in DirectX as it is bound to the sampler (it is a sampler state after all) it would have to be set before every render call. However it shouldn?t make any API difference really, as we can just have a field somewhere and the parse it along when needed. Cheers, Matija. From: Jayathirth Rao Daarapuram Venkatesh Murthy Sent: Wednesday, 21 June 2023 13:09 To: Nir Lisker; Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In OpenGL we set GL_LINEAR by default at : https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L221 And Metal supports only two types of Min/Max filters : Nearest(default) and Linear. So even if D3D supports multiple types we might be limited to support only these 2 filters for all platforms. Thanks, Jay From: openjfx-dev on behalf of Nir Lisker Date: Wednesday, 21 June 2023 at 3:57 PM To: Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial First of all, please excuse directly e-mailing you earlier today. Working with mailing lists is quite new for me and apparently I forgot to add the mailing list to cc. I didn't get any private email, so you seem to be doing better than you thought with the mailing list :) With the OpenGL-side I do have some experience. Concerning the D3D-side of things it would probably mean convincing Somebody that it is a good idea to finally apply the suggested change. There would be some API change required of course. As a basic concept it would probably be sensible to add this as a parameter to the PhonMaterial-class. Alternatively it might make sense to add a ?Texture? class that is used a a DiffuseMap in the PhonMaterial. But that seems slightly overkill. Where to put the new methods in the Java side is not the concerning part, it's how to create methods that match all the pipelines. In D3D, the method for setting the filter is detailed in [1], and its possible parameters in [2][3][4]. So suppose that I'm looking at the list of available filter types there: D3DTEXF_NONE, D3DTEXF_POINT, D3DTEXF_LINEAR, D3DTEXF_ANISOTROPIC, D3DTEXF_PYRAMIDALQUAD, D3DTEXF_GAUSSIANQUAD, D3DTEXF_CONVOLUTIONMONO, if OpenGL supports a somewhat different set of filters, we will have some clashes in the Java API side. Generally, we would like to give as much flexibility to the user as possible, but need to be careful with platform-specific functionality. We could round *some* corners. For example, I think that if we have an enum for the filter types above that is a union of the ones available in the different pipelines, and if a few are supported by only one of the pipelines, we could note it in the docs and get away with it (something similar to a conditional feature). However, if the whole native pipeline setup for texture filtering is different, which means a different set of Java API methods per pipeline, then that's too much. All this means is that to continue we need to figure out what the API for each pipeline looks like, what's the most functionality we can have for each pipeline, and then how we can unite them into a single Java API with the hopes of being able to reconcile the differences "well enough" (whatever that will mean). [1] https://learn.microsoft.com/en-us/windows/win32/api/d3d9helper/nf-d3d9helper-idirect3ddevice9-setsamplerstate [2] https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dtexturefiltertype [3] https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dsamplerstatetype [4] https://learn.microsoft.com/en-us/windows/win32/direct3d9/vertex-textures-in-vs-3-0 On Wed, Jun 21, 2023 at 12:45?PM Matija Brown > wrote: First of all, please excuse directly e-mailing you earlier today. Working with mailing lists is quite new for me and apparently I forgot to add the mailing list to cc. With the OpenGL-side I do have some experience. Concerning the D3D-side of things it would probably mean convincing Somebody that it is a good idea to finally apply the suggested change. There would be some API change required of course. As a basic concept it would probably be sensible to add this as a parameter to the PhonMaterial-class. Alternatively it might make sense to add a ?Texture? class that is used a a DiffuseMap in the PhonMaterial. But that seems slightly overkill. As I am not very well acquainted with current design principles of this library, these things should lie in more experience contributors hands. From: Nir Lisker Sent: Tuesday, 20 June 2023 20:50 To: Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? There is no API to set the texture filter. If you would like to contribute and add it, I can help. It needs to be compatible with both Direct3D and OpenGL (not sure how the work on Metal is going), so this can be a challenge. For the D3D side, see this issue in JBS [1]. The relevant code is at [2]. I didn't look at the OpenGL side. - Nir [1] https://bugs.openjdk.org/browse/JDK-8092272 [2] https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc#L621 On Mon, Jun 19, 2023 at 10:15?PM Matija Brown > wrote: On my never ending journey of building a Minecraft-clone in every graphics-framework available, I have come across JavaFX for the next attempt. However a minor inconvenience has crossed my path in the process: Using the (very well developed!) 2D-Graphics displaying pixel-art style images is no trouble whatsoever. Simply rendering it to a canvas and disabling smoothing does the job just fine. Unfortunately, I have been unable to figure out how to achieve a similar thing using the 3D-Graphics engine and the PhongMaterial that comes with it. Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? Unfortunately the latest information I could find online was from about 2013 and much has (probably) changed since then. Thus the question is being posed once again. I whish to excuse myself for probably repeating a fairly common question, Kind regards, Matija Brown. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Jun 22 04:25:34 2023 From: jayathirth.d.v at oracle.com (Jayathirth Rao Daarapuram Venkatesh Murthy) Date: Thu, 22 Jun 2023 04:25:34 +0000 Subject: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In-Reply-To: References: Message-ID: Correcting myself: Currently I am working on Metal implementation of Texture maps in JavaFX 3D : https://bugs.openjdk.org/browse/JDK-8310109 and not on adding nearest sampling(which last mail can imply). Thanks, Jay From: openjfx-dev on behalf of Jayathirth Rao Daarapuram Venkatesh Murthy Date: Thursday, 22 June 2023 at 9:22 AM To: Nir Lisker , Kevin Rushforth Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Currently I am working on Metal implementation of the same and has no bandwidth to work on additional OpenGL thing. But I can help in reviewing the code if we come up with addition of nearest filtering. Thanks, Jay From: openjfx-dev on behalf of Nir Lisker Date: Wednesday, 21 June 2023 at 9:40 PM To: Kevin Rushforth Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial If I remember correctly, in OpenGL you parse the texture filter when the texture is being created, while in DirectX as it is bound to the sampler (it is a sampler state after all) it would have to be set before every render call. However it shouldn?t make any API difference really, as we can just have a field somewhere and the parse it along when needed. Yes, the JBS ticket mentions this difference as well. Since Kevin approved this feature and the API seems to converge nicely between the pipelines, we can start the work. I'm somewhat busy with other tasks as of late, but I will try to formulate an API. Matija or Jay, if one of you can start investigating the changes to the OpenGL pipeline we could create a branch in the sandbox repo and work there. On Wed, Jun 21, 2023 at 4:03?PM Kevin Rushforth > wrote: My preference would be to add support only for Linear and Nearest in any case. -- Kevin On 6/21/2023 4:48 AM, Matija Brown wrote: As Jayathrith said, in OpenGL as well as Metal only NEAREST and LINEAR filters are available. There might be a way of getting around it by implementing some own algorithm for OpenGL and Metal but that seem slightly over the top. So either one would have to keep the options limited to the two supported everywhere or go with the ?conditional? features. Having had a look at DirectX the APIs seem not to differ too much. If I remember correctly, in OpenGL you parse the texture filter when the texture is being created, while in DirectX as it is bound to the sampler (it is a sampler state after all) it would have to be set before every render call. However it shouldn?t make any API difference really, as we can just have a field somewhere and the parse it along when needed. Cheers, Matija. From: Jayathirth Rao Daarapuram Venkatesh Murthy Sent: Wednesday, 21 June 2023 13:09 To: Nir Lisker; Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In OpenGL we set GL_LINEAR by default at : https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L221 And Metal supports only two types of Min/Max filters : Nearest(default) and Linear. So even if D3D supports multiple types we might be limited to support only these 2 filters for all platforms. Thanks, Jay From: openjfx-dev on behalf of Nir Lisker Date: Wednesday, 21 June 2023 at 3:57 PM To: Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial First of all, please excuse directly e-mailing you earlier today. Working with mailing lists is quite new for me and apparently I forgot to add the mailing list to cc. I didn't get any private email, so you seem to be doing better than you thought with the mailing list :) With the OpenGL-side I do have some experience. Concerning the D3D-side of things it would probably mean convincing Somebody that it is a good idea to finally apply the suggested change. There would be some API change required of course. As a basic concept it would probably be sensible to add this as a parameter to the PhonMaterial-class. Alternatively it might make sense to add a ?Texture? class that is used a a DiffuseMap in the PhonMaterial. But that seems slightly overkill. Where to put the new methods in the Java side is not the concerning part, it's how to create methods that match all the pipelines. In D3D, the method for setting the filter is detailed in [1], and its possible parameters in [2][3][4]. So suppose that I'm looking at the list of available filter types there: D3DTEXF_NONE, D3DTEXF_POINT, D3DTEXF_LINEAR, D3DTEXF_ANISOTROPIC, D3DTEXF_PYRAMIDALQUAD, D3DTEXF_GAUSSIANQUAD, D3DTEXF_CONVOLUTIONMONO, if OpenGL supports a somewhat different set of filters, we will have some clashes in the Java API side. Generally, we would like to give as much flexibility to the user as possible, but need to be careful with platform-specific functionality. We could round *some* corners. For example, I think that if we have an enum for the filter types above that is a union of the ones available in the different pipelines, and if a few are supported by only one of the pipelines, we could note it in the docs and get away with it (something similar to a conditional feature). However, if the whole native pipeline setup for texture filtering is different, which means a different set of Java API methods per pipeline, then that's too much. All this means is that to continue we need to figure out what the API for each pipeline looks like, what's the most functionality we can have for each pipeline, and then how we can unite them into a single Java API with the hopes of being able to reconcile the differences "well enough" (whatever that will mean). [1] https://learn.microsoft.com/en-us/windows/win32/api/d3d9helper/nf-d3d9helper-idirect3ddevice9-setsamplerstate [2] https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dtexturefiltertype [3] https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dsamplerstatetype [4] https://learn.microsoft.com/en-us/windows/win32/direct3d9/vertex-textures-in-vs-3-0 On Wed, Jun 21, 2023 at 12:45?PM Matija Brown > wrote: First of all, please excuse directly e-mailing you earlier today. Working with mailing lists is quite new for me and apparently I forgot to add the mailing list to cc. With the OpenGL-side I do have some experience. Concerning the D3D-side of things it would probably mean convincing Somebody that it is a good idea to finally apply the suggested change. There would be some API change required of course. As a basic concept it would probably be sensible to add this as a parameter to the PhonMaterial-class. Alternatively it might make sense to add a ?Texture? class that is used a a DiffuseMap in the PhonMaterial. But that seems slightly overkill. As I am not very well acquainted with current design principles of this library, these things should lie in more experience contributors hands. From: Nir Lisker Sent: Tuesday, 20 June 2023 20:50 To: Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? There is no API to set the texture filter. If you would like to contribute and add it, I can help. It needs to be compatible with both Direct3D and OpenGL (not sure how the work on Metal is going), so this can be a challenge. For the D3D side, see this issue in JBS [1]. The relevant code is at [2]. I didn't look at the OpenGL side. - Nir [1] https://bugs.openjdk.org/browse/JDK-8092272 [2] https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc#L621 On Mon, Jun 19, 2023 at 10:15?PM Matija Brown > wrote: On my never ending journey of building a Minecraft-clone in every graphics-framework available, I have come across JavaFX for the next attempt. However a minor inconvenience has crossed my path in the process: Using the (very well developed!) 2D-Graphics displaying pixel-art style images is no trouble whatsoever. Simply rendering it to a canvas and disabling smoothing does the job just fine. Unfortunately, I have been unable to figure out how to achieve a similar thing using the 3D-Graphics engine and the PhongMaterial that comes with it. Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? Unfortunately the latest information I could find online was from about 2013 and much has (probably) changed since then. Thus the question is being posed once again. I whish to excuse myself for probably repeating a fairly common question, Kind regards, Matija Brown. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kpk at openjdk.org Thu Jun 22 06:07:10 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 22 Jun 2023 06:07:10 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow In-Reply-To: References: Message-ID: <51KoSv9YCgj_2dt5zOH3xsyZkBJLQDMGt6iszSwRpeY=.e7b00084-f09e-4f6d-b4ac-df5cb11eacd8@github.com> On Wed, 21 Jun 2023 22:59:41 GMT, Andy Goryachev wrote: >> The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when Text node was embedded in TextFlow. Hence wrong character index value was calculated for the same. >> >> Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index. >> >> Added tests to validate the changes. > > Looks like Text.hitTest() does not return the right information (charIndex=0, leading) for text on either the second line, or a wrapped line. (mouse over over 2nd/3rd lines): > > ![Screenshot 2023-06-21 at 15 56 30](https://github.com/openjdk/jfx/assets/107069028/19ed50e0-453d-4aea-8683-ef1e1ff95e64) Thanks for pointing out the issue @andy-goryachev-oracle . It works when content of one Text node exceeds one line or is wrapped but this is not working when more than one node is present in TextFlow and nodes exceeds one line. This is an issue. I will look into this. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1602055806 From thiago.sayao at gmail.com Thu Jun 22 09:56:48 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 22 Jun 2023 06:56:48 -0300 Subject: Vulkan Message-ID: Hi, Just curiosity. Would a Vulkan implementation offer any improvement over OpenGL in the case of JavaFX? I see that GTK has a Vulkan pipeline. Wayland too, it feels so fast and fluid. And why metal and not Vulkan since it's cross platform and metal isn't? Warning: It may be a stupid question. :) -- Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From org.openjdk at io7m.com Thu Jun 22 10:14:29 2023 From: org.openjdk at io7m.com (Mark Raynsford) Date: Thu, 22 Jun 2023 10:14:29 +0000 Subject: Vulkan In-Reply-To: References: Message-ID: <20230622101429.70fb48c0@workstation01.int.arc7.info> On 2023-06-22T06:56:48 -0300 Thiago Milczarek Say?o wrote: > Hi, > > Just curiosity. Would a Vulkan implementation offer any improvement over > OpenGL in the case of JavaFX? > > I see that GTK has a Vulkan pipeline. > > Wayland too, it feels so fast and fluid. > > And why metal and not Vulkan since it's cross platform and metal isn't? > > Warning: It may be a stupid question. :) I second, third, and fourth this. I really don't know why any project is pursuing anything other than a Vulkan backend for rendering; the tools are better, the API is not utterly error-prone like OpenGL, and it works on every platform (assuming the presence of MoltenVK for Apple's walled garden). -- Mark Raynsford | https://www.io7m.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From tsayao at openjdk.org Thu Jun 22 11:45:30 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 22 Jun 2023 11:45:30 GMT Subject: RFR: 8308644: [Linux] Simplify and fix small bugs on glass key related events [v5] In-Reply-To: References: Message-ID: > This PR adds missing key mappings, fixes "Alt Gr" for some systems and cleans `process_key`a little bit. 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 16 additional commits since the last revision: - Minimize changes - Merge branch 'master' into gdk_to_glass_key_map - Forgot test code - Back to hash - Revert key lock change because it has different behaviour - Revert modifier change + Remove F13 -> F24 - Remove print statement - Use GDK instead of X calls (to ease in a future wayland implementation) - Avoid sending unknown key event - GDK_META_MASK is not ALT - ... and 6 more: https://git.openjdk.org/jfx/compare/af7d366c...aad021a6 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1143/files - new: https://git.openjdk.org/jfx/pull/1143/files/06968167..aad021a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1143&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1143&range=03-04 Stats: 40615 lines in 878 files changed: 12420 ins; 3782 del; 24413 mod Patch: https://git.openjdk.org/jfx/pull/1143.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1143/head:pull/1143 PR: https://git.openjdk.org/jfx/pull/1143 From tsayao at openjdk.org Thu Jun 22 11:48:14 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 22 Jun 2023 11:48:14 GMT Subject: RFR: 8308644: [Linux] Missing mappings for dead keys + Alt Gr [v4] In-Reply-To: <13UjedHW5zEt_IXJBjSFLqOb040rAoZYOn-QYdTKg-8=.076434cb-771a-47d5-a5af-db242cd01672@github.com> References: <13UjedHW5zEt_IXJBjSFLqOb040rAoZYOn-QYdTKg-8=.076434cb-771a-47d5-a5af-db242cd01672@github.com> Message-ID: <3aVebzeIjHL71neOdGyENTXB6xnYTIvevYNhZ5Ni37k=.4f72d2dc-fe19-4189-8c06-e24f485ac762@github.com> On Wed, 24 May 2023 00:54:27 GMT, Thiago Milczarek Sayao wrote: >> This PR adds missing key mappings for dead keys and fixes "Alt Gr" for some systems. > > Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: > > - Forgot test code > - Back to hash Changed the scope of the PR to a minimum more "mergeable" approach. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1143#issuecomment-1602495328 From kevin.rushforth at oracle.com Thu Jun 22 12:03:26 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 22 Jun 2023 05:03:26 -0700 Subject: Vulkan In-Reply-To: <20230622101429.70fb48c0@workstation01.int.arc7.info> References: <20230622101429.70fb48c0@workstation01.int.arc7.info> Message-ID: Apple's native API is Metal, and that's what we are going to use on Mac platforms. If we were to do a Vulkan port it would be for Linux (we use DirectX on Windows). It's certainly something we could consider for the future, but is not a high priority. -- Kevin On 6/22/2023 3:14 AM, Mark Raynsford wrote: > On 2023-06-22T06:56:48 -0300 > Thiago Milczarek Say?o wrote: > >> Hi, >> >> Just curiosity. Would a Vulkan implementation offer any improvement over >> OpenGL in the case of JavaFX? >> >> I see that GTK has a Vulkan pipeline. >> >> Wayland too, it feels so fast and fluid. >> >> And why metal and not Vulkan since it's cross platform and metal isn't? >> >> Warning: It may be a stupid question. :) > I second, third, and fourth this. > > I really don't know why any project is pursuing anything other than a > Vulkan backend for rendering; the tools are better, the API is not > utterly error-prone like OpenGL, and it works on every platform > (assuming the presence of MoltenVK for Apple's walled garden). > From tsayao at openjdk.org Thu Jun 22 12:06:40 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 22 Jun 2023 12:06:40 GMT Subject: RFR: 8273379: GTK3 stops sending key events during drag and drop [v32] In-Reply-To: References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com> Message-ID: <9X_YU6RvD8znwlzgUW9NeCKstOfXGm9lDpU1b-Az3Q4=.e37477de-51b3-4950-8019-f08982f169c3@github.com> On Sat, 6 May 2023 21:20:59 GMT, Thiago Milczarek Sayao wrote: >> This PR fixes 8273379. >> >> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. >> >> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383). >> >> There's also some cleaup. >> >> To do general testing (two tests were added): >> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar` >> >> Information for reviewing: >> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started (`WindowContextBase::sm_mouse_drag_window`); >> * There's a new `DragSourceContext` instead of global variables; >> * DragView were simplified; >> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag); >> * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` will notify java about the button release and set `DnDGesture` to null before the end of the DND. >> * `gdk_drag_find_window_for_screen` -> pass the DragView window to be ignored (as it would "steal" destination motion events); >> * The Scenario were the drag source window closes during the drag is now covered; >> * It does not rely on `gdk_threads_add_idle` because it may be inconsistent. >> >> >> ![image](https://user-images.githubusercontent.com/30704286/213877115-18f274ff-18c9-4d38-acc4-449f24174ecc.png) >> ![image](https://user-images.githubusercontent.com/30704286/213877140-1d24c293-d70f-46e6-b040-c49170d2aa9a.png) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits: > > - Merge branch 'master' into 8273379-dnd-keys > - Merge branch 'master' into 8273379-dnd-keys > - Merge branch 'master' into 8273379-dnd-keys > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - ... and 68 more: https://git.openjdk.org/jfx/compare/c50ce609...53ee86e8 Since it makes sense to not send key events during DND, I'm closing it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/986#issuecomment-1602517385 From tsayao at openjdk.org Thu Jun 22 12:06:41 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 22 Jun 2023 12:06:41 GMT Subject: Withdrawn: 8273379: GTK3 stops sending key events during drag and drop In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com> References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com> Message-ID: On Tue, 27 Dec 2022 13:19:06 GMT, Thiago Milczarek Sayao wrote: > This PR fixes 8273379. > > I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. > > It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383). > > There's also some cleaup. > > To do general testing (two tests were added): > `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar` > > Information for reviewing: > * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started (`WindowContextBase::sm_mouse_drag_window`); > * There's a new `DragSourceContext` instead of global variables; > * DragView were simplified; > * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag); > * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` will notify java about the button release and set `DnDGesture` to null before the end of the DND. > * `gdk_drag_find_window_for_screen` -> pass the DragView window to be ignored (as it would "steal" destination motion events); > * The Scenario were the drag source window closes during the drag is now covered; > * It does not rely on `gdk_threads_add_idle` because it may be inconsistent. > > > ![image](https://user-images.githubusercontent.com/30704286/213877115-18f274ff-18c9-4d38-acc4-449f24174ecc.png) > ![image](https://user-images.githubusercontent.com/30704286/213877140-1d24c293-d70f-46e6-b040-c49170d2aa9a.png) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/986 From kcr at openjdk.org Thu Jun 22 12:32:14 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 22 Jun 2023 12:32:14 GMT Subject: Integrated: 8180066: Convert package.html files to package-info.java In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 15:05:47 GMT, Kevin Rushforth wrote: > This is a doc cleanup task to convert all `package.html` files to `package-info.java`, which is the recommended way to provide package documentation. > > The first commit is the result of running a shell script that @jonathan-gibbons provided. The second commit removes an errant `

    ` tag from the `package-info.java` for one package, `javafx.util.converter` that is unneeded and unwanted. That same file also had a redundant first sentence, which was coincidentally removed by the tool, so once I removed the `

    ` tag the docs for that package now looks good and matches the other packages. There are no other changes in the javadoc-generated API docs. > > One thing I didn't do is add a ` *` at the beginning of the lines that are now part of a javadoc-style comment block. This minimizes the diffs, but it means we won't be using the usual pattern for those comment blocks. I'm inclined to file a follow-up issue rather than changing that now. This pull request has now been integrated. Changeset: c2246159 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/c224615991fb0f3647c21786ecd68b78ade4bcb6 Stats: 2982 lines in 68 files changed: 1289 ins; 1649 del; 44 mod 8180066: Convert package.html files to package-info.java Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1159 From nlisker at gmail.com Thu Jun 22 13:25:54 2023 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 22 Jun 2023 16:25:54 +0300 Subject: Vulkan In-Reply-To: References: <20230622101429.70fb48c0@workstation01.int.arc7.info> Message-ID: The Vulkan pipeline option has been brought up several times over the past years. It's a good addition, but it's a lot of work and there aren't enough people who volunteered to work on it. Even "upgrading" the DirectX implementation from 9 to 11 hasn't taken off for the same reason. On Thu, Jun 22, 2023 at 3:04?PM Kevin Rushforth wrote: > Apple's native API is Metal, and that's what we are going to use on Mac > platforms. If we were to do a Vulkan port it would be for Linux (we use > DirectX on Windows). It's certainly something we could consider for the > future, but is not a high priority. > > -- Kevin > > > On 6/22/2023 3:14 AM, Mark Raynsford wrote: > > On 2023-06-22T06:56:48 -0300 > > Thiago Milczarek Say?o wrote: > > > >> Hi, > >> > >> Just curiosity. Would a Vulkan implementation offer any improvement over > >> OpenGL in the case of JavaFX? > >> > >> I see that GTK has a Vulkan pipeline. > >> > >> Wayland too, it feels so fast and fluid. > >> > >> And why metal and not Vulkan since it's cross platform and metal isn't? > >> > >> Warning: It may be a stupid question. :) > > I second, third, and fourth this. > > > > I really don't know why any project is pursuing anything other than a > > Vulkan backend for rendering; the tools are better, the API is not > > utterly error-prone like OpenGL, and it works on every platform > > (assuming the presence of MoltenVK for Apple's walled garden). > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.vos at gluonhq.com Thu Jun 22 14:21:35 2023 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 22 Jun 2023 16:21:35 +0200 Subject: Vulkan In-Reply-To: References: <20230622101429.70fb48c0@workstation01.int.arc7.info> Message-ID: I agree with Nir. For years now, I'd love to have a Vulkan pipeline, not just for desktop linux but for the embedded/mobile platforms as well. But it's a lot of work indeed. It's easy to go for the first 90%, or even more. But the edge cases are the ones that will consume lots of time. I wish we could find a sponsor for this, but that isn't easy. - Johan On Thu, Jun 22, 2023 at 3:27?PM Nir Lisker wrote: > The Vulkan pipeline option has been brought up several times over the past > years. It's a good addition, but it's a lot of work and there aren't enough > people who volunteered to work on it. > > Even "upgrading" the DirectX implementation from 9 to 11 hasn't taken off > for the same reason. > > On Thu, Jun 22, 2023 at 3:04?PM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Apple's native API is Metal, and that's what we are going to use on Mac >> platforms. If we were to do a Vulkan port it would be for Linux (we use >> DirectX on Windows). It's certainly something we could consider for the >> future, but is not a high priority. >> >> -- Kevin >> >> >> On 6/22/2023 3:14 AM, Mark Raynsford wrote: >> > On 2023-06-22T06:56:48 -0300 >> > Thiago Milczarek Say?o wrote: >> > >> >> Hi, >> >> >> >> Just curiosity. Would a Vulkan implementation offer any improvement >> over >> >> OpenGL in the case of JavaFX? >> >> >> >> I see that GTK has a Vulkan pipeline. >> >> >> >> Wayland too, it feels so fast and fluid. >> >> >> >> And why metal and not Vulkan since it's cross platform and metal isn't? >> >> >> >> Warning: It may be a stupid question. :) >> > I second, third, and fourth this. >> > >> > I really don't know why any project is pursuing anything other than a >> > Vulkan backend for rendering; the tools are better, the API is not >> > utterly error-prone like OpenGL, and it works on every platform >> > (assuming the presence of MoltenVK for Apple's walled garden). >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matija.Brown at outlook.de Thu Jun 22 16:35:16 2023 From: Matija.Brown at outlook.de (Matija Brown) Date: Thu, 22 Jun 2023 16:35:16 +0000 Subject: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In-Reply-To: References: Message-ID: I?ll do the OpenGL ? have done quite a bit with Vulkan and GL in the past so there?s no problem there. Certainly usefull if you would do some reviewing ? if you finish the Metal texture maps someone will surely find themselves to expand it with sampling. Tomorrow I?ll give a short summary on what would be to do for OpenGL, as we have that for D3D already. Then do a little example probably ? doesn?t really seem too much work to me? Thanks, Matija. From: Jayathirth Rao Daarapuram Venkatesh Murthy Sent: Thursday, 22 June 2023 06:28 To: Nir Lisker; Kevin Rushforth Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Correcting myself: Currently I am working on Metal implementation of Texture maps in JavaFX 3D : https://bugs.openjdk.org/browse/JDK-8310109 and not on adding nearest sampling(which last mail can imply). Thanks, Jay From: openjfx-dev on behalf of Jayathirth Rao Daarapuram Venkatesh Murthy Date: Thursday, 22 June 2023 at 9:22 AM To: Nir Lisker , Kevin Rushforth Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Currently I am working on Metal implementation of the same and has no bandwidth to work on additional OpenGL thing. But I can help in reviewing the code if we come up with addition of nearest filtering. Thanks, Jay From: openjfx-dev on behalf of Nir Lisker Date: Wednesday, 21 June 2023 at 9:40 PM To: Kevin Rushforth Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial If I remember correctly, in OpenGL you parse the texture filter when the texture is being created, while in DirectX as it is bound to the sampler (it is a sampler state after all) it would have to be set before every render call. However it shouldn?t make any API difference really, as we can just have a field somewhere and the parse it along when needed. Yes, the JBS ticket mentions this difference as well. Since Kevin approved this feature and the API seems to converge nicely between the pipelines, we can start the work. I'm somewhat busy with other tasks as of late, but I will try to formulate an API. Matija or Jay, if one of you can start investigating the changes to the OpenGL pipeline we could create a branch in the sandbox repo and work there. On Wed, Jun 21, 2023 at 4:03?PM Kevin Rushforth > wrote: My preference would be to add support only for Linear and Nearest in any case. -- Kevin On 6/21/2023 4:48 AM, Matija Brown wrote: As Jayathrith said, in OpenGL as well as Metal only NEAREST and LINEAR filters are available. There might be a way of getting around it by implementing some own algorithm for OpenGL and Metal but that seem slightly over the top. So either one would have to keep the options limited to the two supported everywhere or go with the ?conditional? features. Having had a look at DirectX the APIs seem not to differ too much. If I remember correctly, in OpenGL you parse the texture filter when the texture is being created, while in DirectX as it is bound to the sampler (it is a sampler state after all) it would have to be set before every render call. However it shouldn?t make any API difference really, as we can just have a field somewhere and the parse it along when needed. Cheers, Matija. From: Jayathirth Rao Daarapuram Venkatesh Murthy Sent: Wednesday, 21 June 2023 13:09 To: Nir Lisker; Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In OpenGL we set GL_LINEAR by default at : https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L221 And Metal supports only two types of Min/Max filters : Nearest(default) and Linear. So even if D3D supports multiple types we might be limited to support only these 2 filters for all platforms. Thanks, Jay From: openjfx-dev on behalf of Nir Lisker Date: Wednesday, 21 June 2023 at 3:57 PM To: Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial First of all, please excuse directly e-mailing you earlier today. Working with mailing lists is quite new for me and apparently I forgot to add the mailing list to cc. I didn't get any private email, so you seem to be doing better than you thought with the mailing list :) With the OpenGL-side I do have some experience. Concerning the D3D-side of things it would probably mean convincing Somebody that it is a good idea to finally apply the suggested change. There would be some API change required of course. As a basic concept it would probably be sensible to add this as a parameter to the PhonMaterial-class. Alternatively it might make sense to add a ?Texture? class that is used a a DiffuseMap in the PhonMaterial. But that seems slightly overkill. Where to put the new methods in the Java side is not the concerning part, it's how to create methods that match all the pipelines. In D3D, the method for setting the filter is detailed in [1], and its possible parameters in [2][3][4]. So suppose that I'm looking at the list of available filter types there: D3DTEXF_NONE, D3DTEXF_POINT, D3DTEXF_LINEAR, D3DTEXF_ANISOTROPIC, D3DTEXF_PYRAMIDALQUAD, D3DTEXF_GAUSSIANQUAD, D3DTEXF_CONVOLUTIONMONO, if OpenGL supports a somewhat different set of filters, we will have some clashes in the Java API side. Generally, we would like to give as much flexibility to the user as possible, but need to be careful with platform-specific functionality. We could round *some* corners. For example, I think that if we have an enum for the filter types above that is a union of the ones available in the different pipelines, and if a few are supported by only one of the pipelines, we could note it in the docs and get away with it (something similar to a conditional feature). However, if the whole native pipeline setup for texture filtering is different, which means a different set of Java API methods per pipeline, then that's too much. All this means is that to continue we need to figure out what the API for each pipeline looks like, what's the most functionality we can have for each pipeline, and then how we can unite them into a single Java API with the hopes of being able to reconcile the differences "well enough" (whatever that will mean). [1] https://learn.microsoft.com/en-us/windows/win32/api/d3d9helper/nf-d3d9helper-idirect3ddevice9-setsamplerstate [2] https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dtexturefiltertype [3] https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dsamplerstatetype [4] https://learn.microsoft.com/en-us/windows/win32/direct3d9/vertex-textures-in-vs-3-0 On Wed, Jun 21, 2023 at 12:45?PM Matija Brown > wrote: First of all, please excuse directly e-mailing you earlier today. Working with mailing lists is quite new for me and apparently I forgot to add the mailing list to cc. With the OpenGL-side I do have some experience. Concerning the D3D-side of things it would probably mean convincing Somebody that it is a good idea to finally apply the suggested change. There would be some API change required of course. As a basic concept it would probably be sensible to add this as a parameter to the PhonMaterial-class. Alternatively it might make sense to add a ?Texture? class that is used a a DiffuseMap in the PhonMaterial. But that seems slightly overkill. As I am not very well acquainted with current design principles of this library, these things should lie in more experience contributors hands. From: Nir Lisker Sent: Tuesday, 20 June 2023 20:50 To: Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? There is no API to set the texture filter. If you would like to contribute and add it, I can help. It needs to be compatible with both Direct3D and OpenGL (not sure how the work on Metal is going), so this can be a challenge. For the D3D side, see this issue in JBS [1]. The relevant code is at [2]. I didn't look at the OpenGL side. - Nir [1] https://bugs.openjdk.org/browse/JDK-8092272 [2] https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc#L621 On Mon, Jun 19, 2023 at 10:15?PM Matija Brown > wrote: On my never ending journey of building a Minecraft-clone in every graphics-framework available, I have come across JavaFX for the next attempt. However a minor inconvenience has crossed my path in the process: Using the (very well developed!) 2D-Graphics displaying pixel-art style images is no trouble whatsoever. Simply rendering it to a canvas and disabling smoothing does the job just fine. Unfortunately, I have been unable to figure out how to achieve a similar thing using the 3D-Graphics engine and the PhongMaterial that comes with it. Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? Unfortunately the latest information I could find online was from about 2013 and much has (probably) changed since then. Thus the question is being posed once again. I whish to excuse myself for probably repeating a fairly common question, Kind regards, Matija Brown. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anivie.x at gmail.com Thu Jun 22 16:57:35 2023 From: anivie.x at gmail.com (Anivie) Date: Fri, 23 Jun 2023 00:57:35 +0800 Subject: Is there any plan to add CSS new features? Message-ID: We all know that the CSS features of javafx are developed based on the W3C CSS2.1 version. Now, the new CSS3 introduces a lot of practical features, which can help us quickly build amazing modern applications. I always think that CSS is an important feature in Javafx, and it is also an important advantage of javafx and other UI frameworks. In recent years, although many CSS features are still being added. But, the CSS features of javafx are constantly lagging behind CSS3, and many commonly used and important functions, are still not available in javafx. Is there any plan to let Javafx update or even refactor the CSS system to bring features of CSS3 to help us build Javafx applications better? -- Anivie -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Thu Jun 22 17:45:38 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Thu, 22 Jun 2023 19:45:38 +0200 Subject: Is there any plan to add CSS new features? In-Reply-To: References: Message-ID: There's a proposal to add implicit transitions: https://github.com/openjdk/jfx/pull/870 But this is not a plan. The feature may or may not come to JavaFX. On Thu, Jun 22, 2023 at 6:57?PM Anivie wrote: > > We all know that the CSS features of javafx are developed based on the W3C CSS2.1 version. Now, the new CSS3 introduces a lot of practical features, which can help us quickly build amazing modern applications. > > I always think that CSS is an important feature in Javafx, and it is also an important advantage of javafx and other UI frameworks. In recent years, although many CSS features are still being added. But, the CSS features of javafx are constantly lagging behind CSS3, and many commonly used and important functions, are still not available in javafx. > > Is there any plan to let Javafx update or even refactor the CSS system to bring features of CSS3 to help us build Javafx applications better? > > -- Anivie From kcr at openjdk.org Thu Jun 22 18:44:14 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 22 Jun 2023 18:44:14 GMT Subject: RFR: 8180066: Convert package.html files to package-info.java In-Reply-To: References: Message-ID: <8uq0hqBBBar6JAN4EIKahw07bzk1TMfXwF8CIDVW3g0=.a81a75bf-b91a-40b5-9254-b0e513b293e4@github.com> On Wed, 21 Jun 2023 15:05:47 GMT, Kevin Rushforth wrote: > One thing I didn't do is add a * at the beginning of the lines that are now part of a javadoc-style comment block. This minimizes the diffs, but it means we won't be using the usual pattern for those comment blocks. I'm inclined to file a follow-up issue rather than changing that now. I filed [JDK-8310667](https://bugs.openjdk.org/browse/JDK-8310667) to track normalizing the javadoc comment blocks. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1159#issuecomment-1603142724 From kcr at openjdk.org Thu Jun 22 18:45:28 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 22 Jun 2023 18:45:28 GMT Subject: RFR: 8310667: Normalize comment blocks in newly-converted package-info.java files Message-ID: This is a follow-up fix for [JDK-8180066](https://bugs.openjdk.org/browse/JDK-8180066). As mentioned in the description of PR #1159, we should normalize the javadoc comment blocks in the `package-info.java` files, which were converted from `package.html`. In addition to being good cleanup, it also resolves a CI test failure that was introduced by [JDK-8180066](https://bugs.openjdk.org/browse/JDK-8180066), and is being tracked by [JDK-8310654](https://bugs.openjdk.org/browse/JDK-8310654). The generated API docs are identical before and after this fix, excluding white-space changes. So the following show zero differences: $ diff -w -r before/build/javadoc after/build/javadoc Additionally, the following now passes, whereas it fails without this fix: $ gradle :graphics:test ------------- Commit messages: - 8310667: Normalize comment blocks in newly-converted package-info.java files Changes: https://git.openjdk.org/jfx/pull/1160/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1160&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310667 Stats: 1368 lines in 39 files changed: 0 ins; 10 del; 1358 mod Patch: https://git.openjdk.org/jfx/pull/1160.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1160/head:pull/1160 PR: https://git.openjdk.org/jfx/pull/1160 From angorya at openjdk.org Fri Jun 23 00:08:09 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 23 Jun 2023 00:08:09 GMT Subject: RFR: 8310667: Normalize comment blocks in newly-converted package-info.java files In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 18:38:43 GMT, Kevin Rushforth wrote: > This is a follow-up fix for [JDK-8180066](https://bugs.openjdk.org/browse/JDK-8180066). As mentioned in the description of PR #1159, we should normalize the javadoc comment blocks in the `package-info.java` files, which were converted from `package.html`. > > In addition to being good cleanup, it also resolves a CI test failure that was introduced by [JDK-8180066](https://bugs.openjdk.org/browse/JDK-8180066), and is being tracked by [JDK-8310654](https://bugs.openjdk.org/browse/JDK-8310654). > > The generated API docs are identical before and after this fix, excluding white-space changes. So the following show zero differences: > > > $ diff -w -r before/build/javadoc after/build/javadoc > > > Additionally, the following now passes, whereas it fails without this fix: > > > $ gradle :graphics:test Marked as reviewed by angorya (Reviewer). There are still whitespace diffs (leading whitespace, see the screenshot), but i think it's ok for all practical purposes. Screenshot 2023-06-22 at 17 03 47 ------------- PR Review: https://git.openjdk.org/jfx/pull/1160#pullrequestreview-1494148655 PR Comment: https://git.openjdk.org/jfx/pull/1160#issuecomment-1603457021 From kpk at openjdk.org Fri Jun 23 04:25:13 2023 From: kpk at openjdk.org (Karthik P K) Date: Fri, 23 Jun 2023 04:25:13 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 06:34:00 GMT, Karthik P K wrote: > The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when Text node was embedded in TextFlow. Hence wrong character index value was calculated for the same. > > Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index. > > Added tests to validate the changes. The cause for above mentioned issue is that, the `line.getRuns()` call in line no.439 in PrismTextLayout.java returns text runs only for the first Text node. Because of this issue correct character index is not calculated. It looks like the issue is in line creation. I will fix this issue along with the character index issue we are fixing already in this PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1603662527 From dollj at xsinet.co.za Fri Jun 23 07:27:21 2023 From: dollj at xsinet.co.za (Jurgen Doll) Date: Fri, 23 Jun 2023 09:27:21 +0200 Subject: Comment for JDK-8289115 - Touch events are not dispatched after upgrade to FX17 In-Reply-To: References: Message-ID: Hi Could someone please add the following lines as comment to the issue JDK-8289115 (https://bugs.openjdk.org/browse/JDK-8289115) Thank you very much. @Praveen please have another look at Capture.pptx and you'll see that *ONLY* MouseEvents are being fired and NO TouchEvents. The test case illustrates exactly what the reporter describes as being the problem. So is reproducible. Note that this appears to be device INdependent, so any TouchScreen running Windows with either touch or pen/stylus, will show no TouchEvents are fired after jfx17-ea+2-win. This bug is a direct result of fixing JDK-8249737 RuntimeException: Too many touch points reported. (https://bugs.openjdk.java.net/browse/JDK-8249737) Please reopen both of these issues. Thanks, Jurgen -------------- next part -------------- An HTML attachment was scrubbed... URL: From aghaisas at openjdk.org Fri Jun 23 10:45:15 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 23 Jun 2023 10:45:15 GMT Subject: RFR: 8302511: HitInfo.toString() throws IllegalArgumentException [v3] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 15:35:42 GMT, Andy Goryachev wrote: >> A recent change in JDK-8304831 ensured that insertionIndex is always computed prior to HitInfo construction, making it possible to remove buggy logic in HitInfo. This change also allows for removal of the 'text' field. >> >> There should be no impact since the constructor is package protected. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > whitespace LGTM. ------------- Marked as reviewed by aghaisas (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1154#pullrequestreview-1494905694 From kpk at openjdk.org Fri Jun 23 12:28:12 2023 From: kpk at openjdk.org (Karthik P K) Date: Fri, 23 Jun 2023 12:28:12 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: On Thu, 15 Jun 2023 19:38:00 GMT, Andy Goryachev wrote: > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale) (I think). Tested the fix in Windows 11 and MacOS 13.3.1. The changes fixes the issue in Windows and in mac, the behavior is as expected with and without the change. Provided couple of minor comments inline. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 176: > 174: while (delta < -halfPixel) { > 175: double d = -pixel; > 176: if(smallShrink(d, desired)) { Minor: Add space after `if` -> `if (` modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 184: > 182: while (delta > halfPixel) { > 183: double d = pixel; > 184: if(smallGrow(d, desired)) { Add space after `if` -> `if (` ------------- Changes requested by kpk (Committer). PR Review: https://git.openjdk.org/jfx/pull/1156#pullrequestreview-1495003754 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1239728406 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1239728609 From kcr at openjdk.org Fri Jun 23 13:58:11 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 23 Jun 2023 13:58:11 GMT Subject: RFR: 8310667: Normalize comment blocks in newly-converted package-info.java files In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 18:38:43 GMT, Kevin Rushforth wrote: > This is a follow-up fix for [JDK-8180066](https://bugs.openjdk.org/browse/JDK-8180066). As mentioned in the description of PR #1159, we should normalize the javadoc comment blocks in the `package-info.java` files, which were converted from `package.html`. > > In addition to being good cleanup, it also resolves a CI test failure that was introduced by [JDK-8180066](https://bugs.openjdk.org/browse/JDK-8180066), and is being tracked by [JDK-8310654](https://bugs.openjdk.org/browse/JDK-8310654). > > The generated API docs are identical before and after this fix, excluding white-space changes. So the following show zero differences: > > > $ diff -w -r before/build/javadoc after/build/javadoc > > > Additionally, the following now passes, whereas it fails without this fix: > > > $ gradle :graphics:test Yes, the whitespace diffs are expected. Running a diff with the option to ignore white spaces shows zero diffs. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1160#issuecomment-1604318978 From kcr at openjdk.org Fri Jun 23 13:58:12 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 23 Jun 2023 13:58:12 GMT Subject: Integrated: 8310667: Normalize comment blocks in newly-converted package-info.java files In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 18:38:43 GMT, Kevin Rushforth wrote: > This is a follow-up fix for [JDK-8180066](https://bugs.openjdk.org/browse/JDK-8180066). As mentioned in the description of PR #1159, we should normalize the javadoc comment blocks in the `package-info.java` files, which were converted from `package.html`. > > In addition to being good cleanup, it also resolves a CI test failure that was introduced by [JDK-8180066](https://bugs.openjdk.org/browse/JDK-8180066), and is being tracked by [JDK-8310654](https://bugs.openjdk.org/browse/JDK-8310654). > > The generated API docs are identical before and after this fix, excluding white-space changes. So the following show zero differences: > > > $ diff -w -r before/build/javadoc after/build/javadoc > > > Additionally, the following now passes, whereas it fails without this fix: > > > $ gradle :graphics:test This pull request has now been integrated. Changeset: 152a43e1 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/152a43e13ed36f781e64b8220ae9c73ec9f05a52 Stats: 1368 lines in 39 files changed: 0 ins; 10 del; 1358 mod 8310667: Normalize comment blocks in newly-converted package-info.java files 8310654: validateSourceSets task fails on javafx/scene/package-info.java after JDK-8180066 Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1160 From angorya at openjdk.org Fri Jun 23 15:40:13 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 23 Jun 2023 15:40:13 GMT Subject: Integrated: 8302511: HitInfo.toString() throws IllegalArgumentException In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 15:40:41 GMT, Andy Goryachev wrote: > A recent change in JDK-8304831 ensured that insertionIndex is always computed prior to HitInfo construction, making it possible to remove buggy logic in HitInfo. This change also allows for removal of the 'text' field. > > There should be no impact since the constructor is package protected. This pull request has now been integrated. Changeset: d2683b9e Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/d2683b9ebcb13361e8b5084e6c7da6c5a0204c93 Stats: 213 lines in 5 files changed: 145 ins; 34 del; 34 mod 8302511: HitInfo.toString() throws IllegalArgumentException Reviewed-by: kpk, aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/1154 From angorya at openjdk.org Fri Jun 23 15:45:23 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 23 Jun 2023 15:45:23 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: On Thu, 15 Jun 2023 19:38:00 GMT, Andy Goryachev wrote: > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale) (I think). fixed, thanks! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1604462569 From angorya at openjdk.org Fri Jun 23 15:45:21 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 23 Jun 2023 15:45:21 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v2] In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale) (I think). Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1156/files - new: https://git.openjdk.org/jfx/pull/1156/files/be67d858..8eab7970 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1156.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1156/head:pull/1156 PR: https://git.openjdk.org/jfx/pull/1156 From kcr at openjdk.org Fri Jun 23 22:01:17 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 23 Jun 2023 22:01:17 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v2] In-Reply-To: References: <1ybACQTFTQ4PqtoPyikEJ0WM0i6p-Sou3BOBKOpCrrA=.fdfe08aa-9458-4e6b-a099-2331a89bf951@github.com> Message-ID: On Fri, 16 Jun 2023 09:45:04 GMT, John Hendrikx wrote: >> I agree that the chosen names `invalidation`, `changes` and `values` are a bit terse. The whole signature (without reading docs) should make it clear you are creating a subscription, but perhaps we can do better. The use of `addListener` can be ruled out as it would conflict with the existing method due to having Lambda's with the same arity (the `values` listener would conflict with `addListener(InvalidationListener)`. Also, an `add` method would probably have users expecting a corresponding `remove` method. >> >> A few ideas listed here: >> >> | invalidation | values | changes | >> |---|---|---| >> |`subscribe(Runnable)`(*)|`subscribe(Consumer)`(*)|`subscribe(BiConsumer)`(*)| >> |`subscribeInvalidations(Runnable)`|`subscribeValues(Consumer)`|`subscribeChanges(BiConsumer)`| >> |`invalidationsTo(Runnable)`|`valuesTo(Consumer)`|`changesTo(BiConsumer)`| >> >> (*) May limit future listener types that have same arity, but can still be a good choice > > On that same topic of naming methods: > > What do people think of `Subscription#unsubscribe`? Should it be `cancel`? Something else? Okay as it is? > > Code example: > > if (subscription != null) { > subscription.unsubscribe(); > subscription = null; > } > | invalidation | values | changes | > |---|---|---| > |`subscribe(Runnable)`(*)|`subscribe(Consumer)`(*)|`subscribe(BiConsumer)`(*)| > |`subscribeInvalidations(Runnable)`|`subscribeValues(Consumer)`|`subscribeChanges(BiConsumer)`| > |`invalidationsTo(Runnable)`|`valuesTo(Consumer)`|`changesTo(BiConsumer)`| > > (*) May limit future listener types that have same arity, but can still be a good choice My preference is in the order you listed them. If we go with `subscribe`, using method name overloading, do want to add a future overload that takes a type with the same arity as one of the existing three, we can always assign a new name to that new method (since adding another overload wouldn't be source compatible, we would likely need a new name at that point). @nlisker @andy-goryachev-oracle @mstr2 - what do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1240440189 From kcr at openjdk.org Fri Jun 23 22:01:18 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 23 Jun 2023 22:01:18 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v2] In-Reply-To: References: <1ybACQTFTQ4PqtoPyikEJ0WM0i6p-Sou3BOBKOpCrrA=.fdfe08aa-9458-4e6b-a099-2331a89bf951@github.com> Message-ID: On Fri, 23 Jun 2023 21:57:03 GMT, Kevin Rushforth wrote: >> On that same topic of naming methods: >> >> What do people think of `Subscription#unsubscribe`? Should it be `cancel`? Something else? Okay as it is? >> >> Code example: >> >> if (subscription != null) { >> subscription.unsubscribe(); >> subscription = null; >> } > >> | invalidation | values | changes | >> |---|---|---| >> |`subscribe(Runnable)`(*)|`subscribe(Consumer)`(*)|`subscribe(BiConsumer)`(*)| >> |`subscribeInvalidations(Runnable)`|`subscribeValues(Consumer)`|`subscribeChanges(BiConsumer)`| >> |`invalidationsTo(Runnable)`|`valuesTo(Consumer)`|`changesTo(BiConsumer)`| >> >> (*) May limit future listener types that have same arity, but can still be a good choice > > My preference is in the order you listed them. If we go with `subscribe`, using method name overloading, do want to add a future overload that takes a type with the same arity as one of the existing three, we can always assign a new name to that new method (since adding another overload wouldn't be source compatible, we would likely need a new name at that point). > > @nlisker @andy-goryachev-oracle @mstr2 - what do you think? > On that same topic of naming methods: > > What do people think of `Subscription#unsubscribe`? Should it be `cancel`? Something else? Okay as it is? OK as is. Especially if we go with one of the two choices with "subscribe" in the name. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1240441669 From angorya at openjdk.org Fri Jun 23 22:31:09 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 23 Jun 2023 22:31:09 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v2] In-Reply-To: References: <1ybACQTFTQ4PqtoPyikEJ0WM0i6p-Sou3BOBKOpCrrA=.fdfe08aa-9458-4e6b-a099-2331a89bf951@github.com> Message-ID: On Fri, 23 Jun 2023 21:58:37 GMT, Kevin Rushforth wrote: >>> | invalidation | values | changes | >>> |---|---|---| >>> |`subscribe(Runnable)`(*)|`subscribe(Consumer)`(*)|`subscribe(BiConsumer)`(*)| >>> |`subscribeInvalidations(Runnable)`|`subscribeValues(Consumer)`|`subscribeChanges(BiConsumer)`| >>> |`invalidationsTo(Runnable)`|`valuesTo(Consumer)`|`changesTo(BiConsumer)`| >>> >>> (*) May limit future listener types that have same arity, but can still be a good choice >> >> My preference is in the order you listed them. If we go with `subscribe`, using method name overloading, do want to add a future overload that takes a type with the same arity as one of the existing three, we can always assign a new name to that new method (since adding another overload wouldn't be source compatible, we would likely need a new name at that point). >> >> @nlisker @andy-goryachev-oracle @mstr2 - what do you think? > >> On that same topic of naming methods: >> >> What do people think of `Subscription#unsubscribe`? Should it be `cancel`? Something else? Okay as it is? > > OK as is. Especially if we go with one of the two choices with "subscribe" in the name. I might prefer the second option, subscribeXXX(). And unsubscribe() is good. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1240464736 From duke at openjdk.org Sat Jun 24 14:17:10 2023 From: duke at openjdk.org (yosbits) Date: Sat, 24 Jun 2023 14:17:10 GMT Subject: RFR: 8304041: [WebView] Text on the left and right of emoji is not visible In-Reply-To: References: Message-ID: On Thu, 6 Apr 2023 20:00:01 GMT, Phil Race wrote: > This fixes a problem with mixing Emoji and regular text in Webview. > The Prism implementation expects that Emoji will not be in the same call to drawString as regular glyphs, > since they need very different handling. > This fix breaks up the runs webview hands to Prism. > The test program in the bug report now renders properly (which it never did before in any release) The G2D implementation of OpenJDK would be helpful in solving this problem. https://github.com/openjdk/jdk/blob/0db63ec76d451295e273c8e3272d013e2c3348ef/src/java.desktop/share/classes/sun/java2d/pipe/GlyphListLoopPipe.java#L41-L59 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1083#issuecomment-1605528349 From duke at openjdk.org Sat Jun 24 17:59:15 2023 From: duke at openjdk.org (Martin Fox) Date: Sat, 24 Jun 2023 17:59:15 GMT Subject: RFR: 8310847: [Mac] Silence OpenGL deprecation warnings Message-ID: <9rhhdkuWDLGtqn3jAaIhtDUt0a9NmGzeZ4eyu1Xd5Hc=.d5260a95-32b2-430b-b9e3-d1c0b6e4417e@github.com> The Mac build issues a lot of warnings including several related to the deprecation of OpenGL in macOS 10.14. Now that the deployment target for JavaFX is 11.0 across the board these warnings are showing up on both M1 and Intel builds. Luckily Apple provides a simply way to silence these warnings by setting a single C preprocessor define. ------------- Commit messages: - Silence OpenGL deprecation warnings on Mac Changes: https://git.openjdk.org/jfx/pull/1161/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1161&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310847 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1161.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1161/head:pull/1161 PR: https://git.openjdk.org/jfx/pull/1161 From mstrauss at openjdk.org Sat Jun 24 19:26:09 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 24 Jun 2023 19:26:09 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v2] In-Reply-To: References: <1ybACQTFTQ4PqtoPyikEJ0WM0i6p-Sou3BOBKOpCrrA=.fdfe08aa-9458-4e6b-a099-2331a89bf951@github.com> Message-ID: <0hH8-9k1R9vTiRnukBMBjkt3UxspriLXm82KpDp8O9Q=.d96da3b6-6efc-41d4-bd5c-11af61f1256b@github.com> On Fri, 23 Jun 2023 22:28:57 GMT, Andy Goryachev wrote: >>> On that same topic of naming methods: >>> >>> What do people think of `Subscription#unsubscribe`? Should it be `cancel`? Something else? Okay as it is? >> >> OK as is. Especially if we go with one of the two choices with "subscribe" in the name. > > I might prefer the second option, subscribeXXX(). > And unsubscribe() is good. I prefer `subscribe` with overloads, as this comes closest to the existing naming scheme of JavaFX listener operations (`addListener` / `removeListener` with overloads). I would also like to see a subscription-style API that works with the existing listener types. This has the advantage of not needing a wrapper for each listener registration, and it can be a drop-in replacement in many places where JavaFX listeners are used today. My suggestion is to have the following new operations: * `subscribe` (`Runnable`, `Consumer`, `BiConsumer`) * `subscribeListener` (`InvalidationListener`, `ChangeListener`) This pairs nicely with the existing operations: * `addListener` (`InvalidationListener`, `ChangeListener`) * `removeListener` (`InvalidationListener`, `ChangeListener`) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1240925324 From mstrauss at openjdk.org Sun Jun 25 02:20:12 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 25 Jun 2023 02:20:12 GMT Subject: RFR: 8310846: Skip failing test InitialWindowSizeTest on Linux Message-ID: Skips `InitialWindowSizeTest` on Linux until [JDK-8310845](https://bugs.openjdk.org/browse/JDK-8310845) is fixed. ------------- Commit messages: - Skip test on Linux Changes: https://git.openjdk.org/jfx/pull/1162/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1162&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310846 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1162.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1162/head:pull/1162 PR: https://git.openjdk.org/jfx/pull/1162 From tsayao at openjdk.org Sun Jun 25 08:02:09 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 25 Jun 2023 08:02:09 GMT Subject: RFR: 8310846: Skip failing test InitialWindowSizeTest on Linux In-Reply-To: References: Message-ID: On Sun, 25 Jun 2023 02:10:58 GMT, Michael Strau? wrote: > Skips `InitialWindowSizeTest` on Linux until [JDK-8310845](https://bugs.openjdk.org/browse/JDK-8310845) is fixed. I will try to fix it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1162#issuecomment-1605920084 From Matija.Brown at outlook.de Sun Jun 25 12:20:41 2023 From: Matija.Brown at outlook.de (Matija Brown) Date: Sun, 25 Jun 2023 12:20:41 +0000 Subject: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In-Reply-To: References: Message-ID: Unfortunately it took a little longer (got busy), but have just had a quick look at the OpenGL side of things. The ES2Texture class appears to handle everything there. There are two create-Methods, but the other one is responsible for MediaFrame stuff and it doesn?t really? make sense to have non-linear filtering there? What?s your opinion? The create method seems to parse in all texture parameters simply as arguments (https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L98), it would probably be best to just add the filtering in there as well. API-wise it?s probably best to have a Texture or DiffuseMap class that the PhongMaterial uses and stores metadata about the Image. However this might be slightly overkill considering there is only this one single parameter we?re trying to add, thus maybe just a flag in PhongMaterial would suffice? Have a nice day, Matija. From: Matija Brown Sent: Thursday, 22 June 2023 18:37 To: Jayathirth Rao Daarapuram Venkatesh Murthy; Nir Lisker; Kevin Rushforth Cc: openjfx-dev at openjdk.org Subject: RE: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial I?ll do the OpenGL ? have done quite a bit with Vulkan and GL in the past so there?s no problem there. Certainly usefull if you would do some reviewing ? if you finish the Metal texture maps someone will surely find themselves to expand it with sampling. Tomorrow I?ll give a short summary on what would be to do for OpenGL, as we have that for D3D already. Then do a little example probably ? doesn?t really seem too much work to me? Thanks, Matija. From: Jayathirth Rao Daarapuram Venkatesh Murthy Sent: Thursday, 22 June 2023 06:28 To: Nir Lisker; Kevin Rushforth Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Correcting myself: Currently I am working on Metal implementation of Texture maps in JavaFX 3D : https://bugs.openjdk.org/browse/JDK-8310109 and not on adding nearest sampling(which last mail can imply). Thanks, Jay From: openjfx-dev on behalf of Jayathirth Rao Daarapuram Venkatesh Murthy Date: Thursday, 22 June 2023 at 9:22 AM To: Nir Lisker , Kevin Rushforth Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Currently I am working on Metal implementation of the same and has no bandwidth to work on additional OpenGL thing. But I can help in reviewing the code if we come up with addition of nearest filtering. Thanks, Jay From: openjfx-dev on behalf of Nir Lisker Date: Wednesday, 21 June 2023 at 9:40 PM To: Kevin Rushforth Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial If I remember correctly, in OpenGL you parse the texture filter when the texture is being created, while in DirectX as it is bound to the sampler (it is a sampler state after all) it would have to be set before every render call. However it shouldn?t make any API difference really, as we can just have a field somewhere and the parse it along when needed. Yes, the JBS ticket mentions this difference as well. Since Kevin approved this feature and the API seems to converge nicely between the pipelines, we can start the work. I'm somewhat busy with other tasks as of late, but I will try to formulate an API. Matija or Jay, if one of you can start investigating the changes to the OpenGL pipeline we could create a branch in the sandbox repo and work there. On Wed, Jun 21, 2023 at 4:03?PM Kevin Rushforth > wrote: My preference would be to add support only for Linear and Nearest in any case. -- Kevin On 6/21/2023 4:48 AM, Matija Brown wrote: As Jayathrith said, in OpenGL as well as Metal only NEAREST and LINEAR filters are available. There might be a way of getting around it by implementing some own algorithm for OpenGL and Metal but that seem slightly over the top. So either one would have to keep the options limited to the two supported everywhere or go with the ?conditional? features. Having had a look at DirectX the APIs seem not to differ too much. If I remember correctly, in OpenGL you parse the texture filter when the texture is being created, while in DirectX as it is bound to the sampler (it is a sampler state after all) it would have to be set before every render call. However it shouldn?t make any API difference really, as we can just have a field somewhere and the parse it along when needed. Cheers, Matija. From: Jayathirth Rao Daarapuram Venkatesh Murthy Sent: Wednesday, 21 June 2023 13:09 To: Nir Lisker; Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In OpenGL we set GL_LINEAR by default at : https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L221 And Metal supports only two types of Min/Max filters : Nearest(default) and Linear. So even if D3D supports multiple types we might be limited to support only these 2 filters for all platforms. Thanks, Jay From: openjfx-dev on behalf of Nir Lisker Date: Wednesday, 21 June 2023 at 3:57 PM To: Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial First of all, please excuse directly e-mailing you earlier today. Working with mailing lists is quite new for me and apparently I forgot to add the mailing list to cc. I didn't get any private email, so you seem to be doing better than you thought with the mailing list :) With the OpenGL-side I do have some experience. Concerning the D3D-side of things it would probably mean convincing Somebody that it is a good idea to finally apply the suggested change. There would be some API change required of course. As a basic concept it would probably be sensible to add this as a parameter to the PhonMaterial-class. Alternatively it might make sense to add a ?Texture? class that is used a a DiffuseMap in the PhonMaterial. But that seems slightly overkill. Where to put the new methods in the Java side is not the concerning part, it's how to create methods that match all the pipelines. In D3D, the method for setting the filter is detailed in [1], and its possible parameters in [2][3][4]. So suppose that I'm looking at the list of available filter types there: D3DTEXF_NONE, D3DTEXF_POINT, D3DTEXF_LINEAR, D3DTEXF_ANISOTROPIC, D3DTEXF_PYRAMIDALQUAD, D3DTEXF_GAUSSIANQUAD, D3DTEXF_CONVOLUTIONMONO, if OpenGL supports a somewhat different set of filters, we will have some clashes in the Java API side. Generally, we would like to give as much flexibility to the user as possible, but need to be careful with platform-specific functionality. We could round *some* corners. For example, I think that if we have an enum for the filter types above that is a union of the ones available in the different pipelines, and if a few are supported by only one of the pipelines, we could note it in the docs and get away with it (something similar to a conditional feature). However, if the whole native pipeline setup for texture filtering is different, which means a different set of Java API methods per pipeline, then that's too much. All this means is that to continue we need to figure out what the API for each pipeline looks like, what's the most functionality we can have for each pipeline, and then how we can unite them into a single Java API with the hopes of being able to reconcile the differences "well enough" (whatever that will mean). [1] https://learn.microsoft.com/en-us/windows/win32/api/d3d9helper/nf-d3d9helper-idirect3ddevice9-setsamplerstate [2] https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dtexturefiltertype [3] https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dsamplerstatetype [4] https://learn.microsoft.com/en-us/windows/win32/direct3d9/vertex-textures-in-vs-3-0 On Wed, Jun 21, 2023 at 12:45?PM Matija Brown > wrote: First of all, please excuse directly e-mailing you earlier today. Working with mailing lists is quite new for me and apparently I forgot to add the mailing list to cc. With the OpenGL-side I do have some experience. Concerning the D3D-side of things it would probably mean convincing Somebody that it is a good idea to finally apply the suggested change. There would be some API change required of course. As a basic concept it would probably be sensible to add this as a parameter to the PhonMaterial-class. Alternatively it might make sense to add a ?Texture? class that is used a a DiffuseMap in the PhonMaterial. But that seems slightly overkill. As I am not very well acquainted with current design principles of this library, these things should lie in more experience contributors hands. From: Nir Lisker Sent: Tuesday, 20 June 2023 20:50 To: Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? There is no API to set the texture filter. If you would like to contribute and add it, I can help. It needs to be compatible with both Direct3D and OpenGL (not sure how the work on Metal is going), so this can be a challenge. For the D3D side, see this issue in JBS [1]. The relevant code is at [2]. I didn't look at the OpenGL side. - Nir [1] https://bugs.openjdk.org/browse/JDK-8092272 [2] https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc#L621 On Mon, Jun 19, 2023 at 10:15?PM Matija Brown > wrote: On my never ending journey of building a Minecraft-clone in every graphics-framework available, I have come across JavaFX for the next attempt. However a minor inconvenience has crossed my path in the process: Using the (very well developed!) 2D-Graphics displaying pixel-art style images is no trouble whatsoever. Simply rendering it to a canvas and disabling smoothing does the job just fine. Unfortunately, I have been unable to figure out how to achieve a similar thing using the 3D-Graphics engine and the PhongMaterial that comes with it. Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? Unfortunately the latest information I could find online was from about 2013 and much has (probably) changed since then. Thus the question is being posed once again. I whish to excuse myself for probably repeating a fairly common question, Kind regards, Matija Brown. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Sun Jun 25 17:49:16 2023 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 25 Jun 2023 20:49:16 +0300 Subject: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In-Reply-To: References: Message-ID: I think that the first question to answer is whether the filtering method is applied to all maps/textures of the material (diffuse, specular, self-illumination) or to each individually. I would imagine that the former makes more sense. If that's the case, the texture filtering parameter will be just one more property in PhongMaterial (perhaps in the Material supertype if it also makes sense for other possible materials - that can be figured out later in any case). On Sun, Jun 25, 2023 at 3:20?PM Matija Brown wrote: > Unfortunately it took a little longer (got busy), but have just had a > quick look at the > > OpenGL side of things. > > > > The ES2Texture class appears to handle everything there. There are two > create-Methods, but the other > > one is responsible for MediaFrame stuff and it doesn?t really? make sense > to have non-linear filtering there? > > What?s your opinion? > > > > The create method seems to parse in all texture parameters simply as > arguments ( > https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L98 > ), > > it would probably be best to just add the filtering in there as well. > > > > API-wise it?s probably best to have a Texture or DiffuseMap class that the > PhongMaterial uses and stores metadata about the Image. > > However this might be slightly overkill considering there is only this one > single parameter we?re trying to add, > > thus maybe just a flag in PhongMaterial would suffice? > > > > Have a nice day, > > Matija. > > *From: *Matija Brown > *Sent: *Thursday, 22 June 2023 18:37 > *To: *Jayathirth Rao Daarapuram Venkatesh Murthy > ; Nir Lisker ; Kevin > Rushforth > *Cc: *openjfx-dev at openjdk.org > *Subject: *RE: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > > > I?ll do the OpenGL ? have done quite a bit with Vulkan and GL in the past > so there?s no problem there. > > Certainly usefull if you would do some reviewing ? if you finish the Metal > texture maps someone will surely find > > themselves to expand it with sampling. > > > > Tomorrow I?ll give a short summary on what would be to do for OpenGL, as > we have that for D3D already. > > Then do a little example probably ? doesn?t really seem too much work to > me? > > > > Thanks, > > Matija. > > > > *From: *Jayathirth Rao Daarapuram Venkatesh Murthy > > *Sent: *Thursday, 22 June 2023 06:28 > *To: *Nir Lisker ; Kevin Rushforth > > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > > > Correcting myself: > > Currently I am working on Metal implementation of Texture maps in JavaFX > 3D : https://bugs.openjdk.org/browse/JDK-8310109 and not on adding > nearest sampling(which last mail can imply). > > > > Thanks, > > Jay > > > > *From: *openjfx-dev on behalf of > Jayathirth Rao Daarapuram Venkatesh Murthy > *Date: *Thursday, 22 June 2023 at 9:22 AM > *To: *Nir Lisker , Kevin Rushforth < > kevin.rushforth at oracle.com> > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > Currently I am working on Metal implementation of the same and has no > bandwidth to work on additional OpenGL thing. > > But I can help in reviewing the code if we come up with addition of > nearest filtering. > > > > Thanks, > > Jay > > > > *From: *openjfx-dev on behalf of Nir > Lisker > *Date: *Wednesday, 21 June 2023 at 9:40 PM > *To: *Kevin Rushforth > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > If I remember correctly, in OpenGL you parse the texture filter when the > texture is being created, while in DirectX as it is bound > > to the sampler (it is a sampler state after all) it would have to be set > before every render call. However it shouldn?t make any > > API difference really, as we can just have a field somewhere and the parse > it along when needed. > > > > Yes, the JBS ticket mentions this difference as well. > > > > Since Kevin approved this feature and the API seems to converge nicely > between the pipelines, we can start the work. I'm somewhat busy with other > tasks as of late, but I will try to formulate an API. Matija or Jay, if one > of you can start investigating the changes to the OpenGL pipeline we could > create a branch in the sandbox repo and work there. > > > > On Wed, Jun 21, 2023 at 4:03?PM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > > My preference would be to add support only for Linear and Nearest in any > case. > > -- Kevin > > On 6/21/2023 4:48 AM, Matija Brown wrote: > > As Jayathrith said, in OpenGL as well as Metal only NEAREST and LINEAR > filters are available. > > > > There might be a way of getting around it by implementing some own > algorithm for OpenGL and Metal but that seem slightly > > over the top. So either one would have to keep the options limited to the > two supported everywhere > > or go with the ?conditional? features. > > > > Having had a look at DirectX the APIs seem not to differ too much. > > If I remember correctly, in OpenGL you parse the texture filter when the > texture is being created, while in DirectX as it is bound > > to the sampler (it is a sampler state after all) it would have to be set > before every render call. However it shouldn?t make any > > API difference really, as we can just have a field somewhere and the parse > it along when needed. > > > > Cheers, > > Matija. > > > > *From: *Jayathirth Rao Daarapuram Venkatesh Murthy > > *Sent: *Wednesday, 21 June 2023 13:09 > *To: *Nir Lisker ; Matija Brown > > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > > > In OpenGL we set GL_LINEAR by default at : > https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L221 > > > > And Metal supports only two types of Min/Max filters : Nearest(default) > and Linear. So even if D3D supports multiple types we might be limited to > support only these 2 filters for all platforms. > > > > Thanks, > > Jay > > > > *From: *openjfx-dev > on behalf of Nir Lisker > > *Date: *Wednesday, 21 June 2023 at 3:57 PM > *To: *Matija Brown > *Cc: *openjfx-dev at openjdk.org > > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > First of all, please excuse directly e-mailing you earlier today. Working > with mailing lists is quite new for me and apparently I forgot to add > > the mailing list to cc. > > > > I didn't get any private email, so you seem to be doing better than you > thought with the mailing list :) > > > > With the OpenGL-side I do have some experience. Concerning the D3D-side of > things it would probably mean convincing > > Somebody that it is a good idea to finally apply the suggested change. > > > > There would be some API change required of course. As a basic concept it > would probably be sensible to add this as a parameter to the > PhonMaterial-class. > > Alternatively it might make sense to add a ?Texture? class that is used a > a DiffuseMap in the PhonMaterial. But that seems slightly overkill. > > > > Where to put the new methods in the Java side is not the concerning part, > it's how to create methods that match all the pipelines. In D3D, the method > for setting the filter is detailed in [1], and its possible parameters in > [2][3][4]. So suppose that I'm looking at the list of available filter > types there: > > D3DTEXF_NONE, D3DTEXF_POINT, D3DTEXF_LINEAR, D3DTEXF_ANISOTROPIC, > D3DTEXF_PYRAMIDALQUAD, D3DTEXF_GAUSSIANQUAD, D3DTEXF_CONVOLUTIONMONO, > > if OpenGL supports a somewhat different set of filters, we will have some > clashes in the Java API side. > > > > Generally, we would like to give as much flexibility to the user as > possible, but need to be careful with platform-specific functionality. We > could round *some* corners. For example, I think that if we have an enum > for the filter types above that is a union of the ones available in the > different pipelines, and if a few are supported by only one of the > pipelines, we could note it in the docs and get away with it (something > similar to a conditional feature). However, if the whole native pipeline > setup for texture filtering is different, which means a different set of > Java API methods per pipeline, then that's too much. > > > > All this means is that to continue we need to figure out what the API for > each pipeline looks like, what's the most functionality we can have for > each pipeline, and then how we can unite them into a single Java API with > the hopes of being able to reconcile the differences "well enough" > (whatever that will mean). > > > > [1] > https://learn.microsoft.com/en-us/windows/win32/api/d3d9helper/nf-d3d9helper-idirect3ddevice9-setsamplerstate > > [2] > https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dtexturefiltertype > > [3] > https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dsamplerstatetype > > [4] > https://learn.microsoft.com/en-us/windows/win32/direct3d9/vertex-textures-in-vs-3-0 > > > > On Wed, Jun 21, 2023 at 12:45?PM Matija Brown > wrote: > > First of all, please excuse directly e-mailing you earlier today. Working > with mailing lists is quite new for me and apparently I forgot to add > > the mailing list to cc. > > > > With the OpenGL-side I do have some experience. Concerning the D3D-side of > things it would probably mean convincing > > Somebody that it is a good idea to finally apply the suggested change. > > > > There would be some API change required of course. As a basic concept it > would probably be sensible to add this as a parameter to the > PhonMaterial-class. > > Alternatively it might make sense to add a ?Texture? class that is used a > a DiffuseMap in the PhonMaterial. But that seems slightly overkill. > > > > As I am not very well acquainted with current design principles of this > library, these things should lie in more experience contributors hands. > > > > *From: *Nir Lisker > *Sent: *Tuesday, 20 June 2023 20:50 > *To: *Matija Brown > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > > > Which leads to the question; Does there, in JavaFX exist something > comparable to setting the texture-sampler to NEAREST > > instead of LINEAR sampling? > > > > There is no API to set the texture filter. If you would like to contribute > and add it, I can help. It needs to be compatible with both Direct3D and > OpenGL (not sure how the work on Metal is going), so this can be a > challenge. > > > > For the D3D side, see this issue in JBS [1]. The relevant code is at [2]. > I didn't look at the OpenGL side. > > > > - Nir > > > > [1] https://bugs.openjdk.org/browse/JDK-8092272 > > [2] > https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc#L621 > > > > On Mon, Jun 19, 2023 at 10:15?PM Matija Brown > wrote: > > On my never ending journey of building a Minecraft-clone in every > graphics-framework available, > > I have come across JavaFX for the next attempt. > > > > > > However a minor inconvenience has crossed my path in the process: > > > > Using the (very well developed!) 2D-Graphics displaying pixel-art style > images is no trouble whatsoever. > > Simply rendering it to a canvas and disabling smoothing does the job just > fine. Unfortunately, I have been > > unable to figure out how to achieve a similar thing using the 3D-Graphics > engine and the PhongMaterial that comes with it. > > > > Which leads to the question; Does there, in JavaFX exist something > comparable to setting the texture-sampler to NEAREST > > instead of LINEAR sampling? > > Unfortunately the latest information I could find online was from about > 2013 and much has (probably) > > changed since then. Thus the question is being posed once again. > > > > > > I whish to excuse myself for probably repeating a fairly common question, > > > > Kind regards, > Matija Brown. > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matija.Brown at outlook.de Sun Jun 25 17:54:03 2023 From: Matija.Brown at outlook.de (Matija Brown) Date: Sun, 25 Jun 2023 17:54:03 +0000 Subject: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In-Reply-To: References: Message-ID: This is a good point you?re bringing up Nir! I?m really not sure on that. On the one hand your interpretation seems the most sensible, but on the other hand I can?t see any use case of NEAREST filtering in specular or self-illumination maps. However giving more options is also always good, and the same way there aren?t really many places (that I?m aware of) one would have NEAREST filtered diffuse maps and use any of the others at all. TLDL: Would work excellently your way API wise, but I?m not certain if it makes sense use-case wise. Thanks, Matija. From: Nir Lisker Sent: Sunday, 25 June 2023 19:49 To: Matija Brown Cc: Jayathirth Rao Daarapuram Venkatesh Murthy; Kevin Rushforth; openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial I think that the first question to answer is whether the filtering method is applied to all maps/textures of the material (diffuse, specular, self-illumination) or to each individually. I would imagine that the former makes more sense. If that's the case, the texture filtering parameter will be just one more property in PhongMaterial (perhaps in the Material supertype if it also makes sense for other possible materials - that can be figured out later in any case). On Sun, Jun 25, 2023 at 3:20?PM Matija Brown > wrote: Unfortunately it took a little longer (got busy), but have just had a quick look at the OpenGL side of things. The ES2Texture class appears to handle everything there. There are two create-Methods, but the other one is responsible for MediaFrame stuff and it doesn?t really? make sense to have non-linear filtering there? What?s your opinion? The create method seems to parse in all texture parameters simply as arguments (https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L98), it would probably be best to just add the filtering in there as well. API-wise it?s probably best to have a Texture or DiffuseMap class that the PhongMaterial uses and stores metadata about the Image. However this might be slightly overkill considering there is only this one single parameter we?re trying to add, thus maybe just a flag in PhongMaterial would suffice? Have a nice day, Matija. From: Matija Brown Sent: Thursday, 22 June 2023 18:37 To: Jayathirth Rao Daarapuram Venkatesh Murthy; Nir Lisker; Kevin Rushforth Cc: openjfx-dev at openjdk.org Subject: RE: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial I?ll do the OpenGL ? have done quite a bit with Vulkan and GL in the past so there?s no problem there. Certainly usefull if you would do some reviewing ? if you finish the Metal texture maps someone will surely find themselves to expand it with sampling. Tomorrow I?ll give a short summary on what would be to do for OpenGL, as we have that for D3D already. Then do a little example probably ? doesn?t really seem too much work to me? Thanks, Matija. From: Jayathirth Rao Daarapuram Venkatesh Murthy Sent: Thursday, 22 June 2023 06:28 To: Nir Lisker; Kevin Rushforth Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Correcting myself: Currently I am working on Metal implementation of Texture maps in JavaFX 3D : https://bugs.openjdk.org/browse/JDK-8310109 and not on adding nearest sampling(which last mail can imply). Thanks, Jay From: openjfx-dev > on behalf of Jayathirth Rao Daarapuram Venkatesh Murthy > Date: Thursday, 22 June 2023 at 9:22 AM To: Nir Lisker >, Kevin Rushforth > Cc: openjfx-dev at openjdk.org > Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Currently I am working on Metal implementation of the same and has no bandwidth to work on additional OpenGL thing. But I can help in reviewing the code if we come up with addition of nearest filtering. Thanks, Jay From: openjfx-dev > on behalf of Nir Lisker > Date: Wednesday, 21 June 2023 at 9:40 PM To: Kevin Rushforth > Cc: openjfx-dev at openjdk.org > Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial If I remember correctly, in OpenGL you parse the texture filter when the texture is being created, while in DirectX as it is bound to the sampler (it is a sampler state after all) it would have to be set before every render call. However it shouldn?t make any API difference really, as we can just have a field somewhere and the parse it along when needed. Yes, the JBS ticket mentions this difference as well. Since Kevin approved this feature and the API seems to converge nicely between the pipelines, we can start the work. I'm somewhat busy with other tasks as of late, but I will try to formulate an API. Matija or Jay, if one of you can start investigating the changes to the OpenGL pipeline we could create a branch in the sandbox repo and work there. On Wed, Jun 21, 2023 at 4:03?PM Kevin Rushforth > wrote: My preference would be to add support only for Linear and Nearest in any case. -- Kevin On 6/21/2023 4:48 AM, Matija Brown wrote: As Jayathrith said, in OpenGL as well as Metal only NEAREST and LINEAR filters are available. There might be a way of getting around it by implementing some own algorithm for OpenGL and Metal but that seem slightly over the top. So either one would have to keep the options limited to the two supported everywhere or go with the ?conditional? features. Having had a look at DirectX the APIs seem not to differ too much. If I remember correctly, in OpenGL you parse the texture filter when the texture is being created, while in DirectX as it is bound to the sampler (it is a sampler state after all) it would have to be set before every render call. However it shouldn?t make any API difference really, as we can just have a field somewhere and the parse it along when needed. Cheers, Matija. From: Jayathirth Rao Daarapuram Venkatesh Murthy Sent: Wednesday, 21 June 2023 13:09 To: Nir Lisker; Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In OpenGL we set GL_LINEAR by default at : https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L221 And Metal supports only two types of Min/Max filters : Nearest(default) and Linear. So even if D3D supports multiple types we might be limited to support only these 2 filters for all platforms. Thanks, Jay From: openjfx-dev on behalf of Nir Lisker Date: Wednesday, 21 June 2023 at 3:57 PM To: Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial First of all, please excuse directly e-mailing you earlier today. Working with mailing lists is quite new for me and apparently I forgot to add the mailing list to cc. I didn't get any private email, so you seem to be doing better than you thought with the mailing list :) With the OpenGL-side I do have some experience. Concerning the D3D-side of things it would probably mean convincing Somebody that it is a good idea to finally apply the suggested change. There would be some API change required of course. As a basic concept it would probably be sensible to add this as a parameter to the PhonMaterial-class. Alternatively it might make sense to add a ?Texture? class that is used a a DiffuseMap in the PhonMaterial. But that seems slightly overkill. Where to put the new methods in the Java side is not the concerning part, it's how to create methods that match all the pipelines. In D3D, the method for setting the filter is detailed in [1], and its possible parameters in [2][3][4]. So suppose that I'm looking at the list of available filter types there: D3DTEXF_NONE, D3DTEXF_POINT, D3DTEXF_LINEAR, D3DTEXF_ANISOTROPIC, D3DTEXF_PYRAMIDALQUAD, D3DTEXF_GAUSSIANQUAD, D3DTEXF_CONVOLUTIONMONO, if OpenGL supports a somewhat different set of filters, we will have some clashes in the Java API side. Generally, we would like to give as much flexibility to the user as possible, but need to be careful with platform-specific functionality. We could round *some* corners. For example, I think that if we have an enum for the filter types above that is a union of the ones available in the different pipelines, and if a few are supported by only one of the pipelines, we could note it in the docs and get away with it (something similar to a conditional feature). However, if the whole native pipeline setup for texture filtering is different, which means a different set of Java API methods per pipeline, then that's too much. All this means is that to continue we need to figure out what the API for each pipeline looks like, what's the most functionality we can have for each pipeline, and then how we can unite them into a single Java API with the hopes of being able to reconcile the differences "well enough" (whatever that will mean). [1] https://learn.microsoft.com/en-us/windows/win32/api/d3d9helper/nf-d3d9helper-idirect3ddevice9-setsamplerstate [2] https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dtexturefiltertype [3] https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dsamplerstatetype [4] https://learn.microsoft.com/en-us/windows/win32/direct3d9/vertex-textures-in-vs-3-0 On Wed, Jun 21, 2023 at 12:45?PM Matija Brown > wrote: First of all, please excuse directly e-mailing you earlier today. Working with mailing lists is quite new for me and apparently I forgot to add the mailing list to cc. With the OpenGL-side I do have some experience. Concerning the D3D-side of things it would probably mean convincing Somebody that it is a good idea to finally apply the suggested change. There would be some API change required of course. As a basic concept it would probably be sensible to add this as a parameter to the PhonMaterial-class. Alternatively it might make sense to add a ?Texture? class that is used a a DiffuseMap in the PhonMaterial. But that seems slightly overkill. As I am not very well acquainted with current design principles of this library, these things should lie in more experience contributors hands. From: Nir Lisker Sent: Tuesday, 20 June 2023 20:50 To: Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? There is no API to set the texture filter. If you would like to contribute and add it, I can help. It needs to be compatible with both Direct3D and OpenGL (not sure how the work on Metal is going), so this can be a challenge. For the D3D side, see this issue in JBS [1]. The relevant code is at [2]. I didn't look at the OpenGL side. - Nir [1] https://bugs.openjdk.org/browse/JDK-8092272 [2] https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc#L621 On Mon, Jun 19, 2023 at 10:15?PM Matija Brown > wrote: On my never ending journey of building a Minecraft-clone in every graphics-framework available, I have come across JavaFX for the next attempt. However a minor inconvenience has crossed my path in the process: Using the (very well developed!) 2D-Graphics displaying pixel-art style images is no trouble whatsoever. Simply rendering it to a canvas and disabling smoothing does the job just fine. Unfortunately, I have been unable to figure out how to achieve a similar thing using the 3D-Graphics engine and the PhongMaterial that comes with it. Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? Unfortunately the latest information I could find online was from about 2013 and much has (probably) changed since then. Thus the question is being posed once again. I whish to excuse myself for probably repeating a fairly common question, Kind regards, Matija Brown. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Sun Jun 25 18:03:57 2023 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 25 Jun 2023 21:03:57 +0300 Subject: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In-Reply-To: References: Message-ID: Perhaps Jay and Kevin can weigh in on this. By the way, I see that the com.sun.prism.Texture interface already defines get/setLinearFiltering methods that specify if the filtering is not linear then it uses a nearest neighbor algorithm. It's not used by the 3D side it seems. On Sun, Jun 25, 2023 at 8:54?PM Matija Brown wrote: > This is a good point you?re bringing up Nir! > > > > I?m really not sure on that. On the one hand your interpretation seems the > most sensible, but on the other hand I can?t see any use case of NEAREST > filtering in specular or self-illumination maps. > > However giving more options is also always good, and the same way there > aren?t really many places (that I?m aware of) one would have NEAREST > filtered diffuse maps and use any of the others at all. > > > > TLDL: Would work excellently your way API wise, but I?m not certain if it > makes sense use-case wise. > > > > Thanks, > > Matija. > > > > *From: *Nir Lisker > *Sent: *Sunday, 25 June 2023 19:49 > *To: *Matija Brown > *Cc: *Jayathirth Rao Daarapuram Venkatesh Murthy > ; Kevin Rushforth ; > openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > > > I think that the first question to answer is whether the filtering method > is applied to all maps/textures of the material (diffuse, specular, > self-illumination) or to each individually. I would imagine that the former > makes more sense. If that's the case, the texture filtering parameter will > be just one more property in PhongMaterial (perhaps in the Material > supertype if it also makes sense for other possible materials - that can be > figured out later in any case). > > > > On Sun, Jun 25, 2023 at 3:20?PM Matija Brown > wrote: > > Unfortunately it took a little longer (got busy), but have just had a > quick look at the > > OpenGL side of things. > > > > The ES2Texture class appears to handle everything there. There are two > create-Methods, but the other > > one is responsible for MediaFrame stuff and it doesn?t really? make sense > to have non-linear filtering there? > > What?s your opinion? > > > > The create method seems to parse in all texture parameters simply as > arguments ( > https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L98 > ), > > it would probably be best to just add the filtering in there as well. > > > > API-wise it?s probably best to have a Texture or DiffuseMap class that the > PhongMaterial uses and stores metadata about the Image. > > However this might be slightly overkill considering there is only this one > single parameter we?re trying to add, > > thus maybe just a flag in PhongMaterial would suffice? > > > > Have a nice day, > > Matija. > > *From: *Matija Brown > *Sent: *Thursday, 22 June 2023 18:37 > *To: *Jayathirth Rao Daarapuram Venkatesh Murthy > ; Nir Lisker ; Kevin > Rushforth > *Cc: *openjfx-dev at openjdk.org > *Subject: *RE: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > > > I?ll do the OpenGL ? have done quite a bit with Vulkan and GL in the past > so there?s no problem there. > > Certainly usefull if you would do some reviewing ? if you finish the Metal > texture maps someone will surely find > > themselves to expand it with sampling. > > > > Tomorrow I?ll give a short summary on what would be to do for OpenGL, as > we have that for D3D already. > > Then do a little example probably ? doesn?t really seem too much work to > me? > > > > Thanks, > > Matija. > > > > *From: *Jayathirth Rao Daarapuram Venkatesh Murthy > > *Sent: *Thursday, 22 June 2023 06:28 > *To: *Nir Lisker ; Kevin Rushforth > > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > > > Correcting myself: > > Currently I am working on Metal implementation of Texture maps in JavaFX > 3D : https://bugs.openjdk.org/browse/JDK-8310109 and not on adding > nearest sampling(which last mail can imply). > > > > Thanks, > > Jay > > > > *From: *openjfx-dev on behalf of > Jayathirth Rao Daarapuram Venkatesh Murthy > *Date: *Thursday, 22 June 2023 at 9:22 AM > *To: *Nir Lisker , Kevin Rushforth < > kevin.rushforth at oracle.com> > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > Currently I am working on Metal implementation of the same and has no > bandwidth to work on additional OpenGL thing. > > But I can help in reviewing the code if we come up with addition of > nearest filtering. > > > > Thanks, > > Jay > > > > *From: *openjfx-dev on behalf of Nir > Lisker > *Date: *Wednesday, 21 June 2023 at 9:40 PM > *To: *Kevin Rushforth > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > If I remember correctly, in OpenGL you parse the texture filter when the > texture is being created, while in DirectX as it is bound > > to the sampler (it is a sampler state after all) it would have to be set > before every render call. However it shouldn?t make any > > API difference really, as we can just have a field somewhere and the parse > it along when needed. > > > > Yes, the JBS ticket mentions this difference as well. > > > > Since Kevin approved this feature and the API seems to converge nicely > between the pipelines, we can start the work. I'm somewhat busy with other > tasks as of late, but I will try to formulate an API. Matija or Jay, if one > of you can start investigating the changes to the OpenGL pipeline we could > create a branch in the sandbox repo and work there. > > > > On Wed, Jun 21, 2023 at 4:03?PM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > > My preference would be to add support only for Linear and Nearest in any > case. > > -- Kevin > > On 6/21/2023 4:48 AM, Matija Brown wrote: > > As Jayathrith said, in OpenGL as well as Metal only NEAREST and LINEAR > filters are available. > > > > There might be a way of getting around it by implementing some own > algorithm for OpenGL and Metal but that seem slightly > > over the top. So either one would have to keep the options limited to the > two supported everywhere > > or go with the ?conditional? features. > > > > Having had a look at DirectX the APIs seem not to differ too much. > > If I remember correctly, in OpenGL you parse the texture filter when the > texture is being created, while in DirectX as it is bound > > to the sampler (it is a sampler state after all) it would have to be set > before every render call. However it shouldn?t make any > > API difference really, as we can just have a field somewhere and the parse > it along when needed. > > > > Cheers, > > Matija. > > > > *From: *Jayathirth Rao Daarapuram Venkatesh Murthy > > *Sent: *Wednesday, 21 June 2023 13:09 > *To: *Nir Lisker ; Matija Brown > > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > > > In OpenGL we set GL_LINEAR by default at : > https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L221 > > > > And Metal supports only two types of Min/Max filters : Nearest(default) > and Linear. So even if D3D supports multiple types we might be limited to > support only these 2 filters for all platforms. > > > > Thanks, > > Jay > > > > *From: *openjfx-dev > on behalf of Nir Lisker > > *Date: *Wednesday, 21 June 2023 at 3:57 PM > *To: *Matija Brown > *Cc: *openjfx-dev at openjdk.org > > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > First of all, please excuse directly e-mailing you earlier today. Working > with mailing lists is quite new for me and apparently I forgot to add > > the mailing list to cc. > > > > I didn't get any private email, so you seem to be doing better than you > thought with the mailing list :) > > > > With the OpenGL-side I do have some experience. Concerning the D3D-side of > things it would probably mean convincing > > Somebody that it is a good idea to finally apply the suggested change. > > > > There would be some API change required of course. As a basic concept it > would probably be sensible to add this as a parameter to the > PhonMaterial-class. > > Alternatively it might make sense to add a ?Texture? class that is used a > a DiffuseMap in the PhonMaterial. But that seems slightly overkill. > > > > Where to put the new methods in the Java side is not the concerning part, > it's how to create methods that match all the pipelines. In D3D, the method > for setting the filter is detailed in [1], and its possible parameters in > [2][3][4]. So suppose that I'm looking at the list of available filter > types there: > > D3DTEXF_NONE, D3DTEXF_POINT, D3DTEXF_LINEAR, D3DTEXF_ANISOTROPIC, > D3DTEXF_PYRAMIDALQUAD, D3DTEXF_GAUSSIANQUAD, D3DTEXF_CONVOLUTIONMONO, > > if OpenGL supports a somewhat different set of filters, we will have some > clashes in the Java API side. > > > > Generally, we would like to give as much flexibility to the user as > possible, but need to be careful with platform-specific functionality. We > could round *some* corners. For example, I think that if we have an enum > for the filter types above that is a union of the ones available in the > different pipelines, and if a few are supported by only one of the > pipelines, we could note it in the docs and get away with it (something > similar to a conditional feature). However, if the whole native pipeline > setup for texture filtering is different, which means a different set of > Java API methods per pipeline, then that's too much. > > > > All this means is that to continue we need to figure out what the API for > each pipeline looks like, what's the most functionality we can have for > each pipeline, and then how we can unite them into a single Java API with > the hopes of being able to reconcile the differences "well enough" > (whatever that will mean). > > > > [1] > https://learn.microsoft.com/en-us/windows/win32/api/d3d9helper/nf-d3d9helper-idirect3ddevice9-setsamplerstate > > [2] > https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dtexturefiltertype > > [3] > https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dsamplerstatetype > > [4] > https://learn.microsoft.com/en-us/windows/win32/direct3d9/vertex-textures-in-vs-3-0 > > > > On Wed, Jun 21, 2023 at 12:45?PM Matija Brown > wrote: > > First of all, please excuse directly e-mailing you earlier today. Working > with mailing lists is quite new for me and apparently I forgot to add > > the mailing list to cc. > > > > With the OpenGL-side I do have some experience. Concerning the D3D-side of > things it would probably mean convincing > > Somebody that it is a good idea to finally apply the suggested change. > > > > There would be some API change required of course. As a basic concept it > would probably be sensible to add this as a parameter to the > PhonMaterial-class. > > Alternatively it might make sense to add a ?Texture? class that is used a > a DiffuseMap in the PhonMaterial. But that seems slightly overkill. > > > > As I am not very well acquainted with current design principles of this > library, these things should lie in more experience contributors hands. > > > > *From: *Nir Lisker > *Sent: *Tuesday, 20 June 2023 20:50 > *To: *Matija Brown > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > > > Which leads to the question; Does there, in JavaFX exist something > comparable to setting the texture-sampler to NEAREST > > instead of LINEAR sampling? > > > > There is no API to set the texture filter. If you would like to contribute > and add it, I can help. It needs to be compatible with both Direct3D and > OpenGL (not sure how the work on Metal is going), so this can be a > challenge. > > > > For the D3D side, see this issue in JBS [1]. The relevant code is at [2]. > I didn't look at the OpenGL side. > > > > - Nir > > > > [1] https://bugs.openjdk.org/browse/JDK-8092272 > > [2] > https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc#L621 > > > > On Mon, Jun 19, 2023 at 10:15?PM Matija Brown > wrote: > > On my never ending journey of building a Minecraft-clone in every > graphics-framework available, > > I have come across JavaFX for the next attempt. > > > > > > However a minor inconvenience has crossed my path in the process: > > > > Using the (very well developed!) 2D-Graphics displaying pixel-art style > images is no trouble whatsoever. > > Simply rendering it to a canvas and disabling smoothing does the job just > fine. Unfortunately, I have been > > unable to figure out how to achieve a similar thing using the 3D-Graphics > engine and the PhongMaterial that comes with it. > > > > Which leads to the question; Does there, in JavaFX exist something > comparable to setting the texture-sampler to NEAREST > > instead of LINEAR sampling? > > Unfortunately the latest information I could find online was from about > 2013 and much has (probably) > > changed since then. Thus the question is being posed once again. > > > > > > I whish to excuse myself for probably repeating a fairly common question, > > > > Kind regards, > Matija Brown. > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Mon Jun 26 05:10:20 2023 From: jayathirth.d.v at oracle.com (Jayathirth Rao Daarapuram Venkatesh Murthy) Date: Mon, 26 Jun 2023 05:10:20 +0000 Subject: [External] : Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In-Reply-To: References: Message-ID: Hi, I am currently working on Metal implementation to solve similar issues and what i have noticed is we can pass properties related to texture filters and mipmapping when we call XXXContext->setMap() call. Because at this place we have an idea what kind of map we are creating and what kind of filters we want to use. As part of https://bugs.openjdk.org/browse/JDK-8310109 I have added default filters is shader itself, but for the next thing I am working on : https://bugs.openjdk.org/browse/JDK-8310658 I am planning to create appropriate sample descriptors with filters and pass it to shader and mostly filter state management will be set through setMap() call. But it is still an idea, will share once I have proper working code for Metal. Thanks, Jay From: Nir Lisker Date: Sunday, 25 June 2023 at 11:34 PM To: Matija Brown Cc: Jayathirth Rao Daarapuram Venkatesh Murthy , Kevin Rushforth , openjfx-dev at openjdk.org Subject: [External] : Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Perhaps Jay and Kevin can weigh in on this. By the way, I see that the com.sun.prism.Texture interface already defines get/setLinearFiltering methods that specify if the filtering is not linear then it uses a nearest neighbor algorithm. It's not used by the 3D side it seems. On Sun, Jun 25, 2023 at 8:54?PM Matija Brown > wrote: This is a good point you?re bringing up Nir! I?m really not sure on that. On the one hand your interpretation seems the most sensible, but on the other hand I can?t see any use case of NEAREST filtering in specular or self-illumination maps. However giving more options is also always good, and the same way there aren?t really many places (that I?m aware of) one would have NEAREST filtered diffuse maps and use any of the others at all. TLDL: Would work excellently your way API wise, but I?m not certain if it makes sense use-case wise. Thanks, Matija. From: Nir Lisker Sent: Sunday, 25 June 2023 19:49 To: Matija Brown Cc: Jayathirth Rao Daarapuram Venkatesh Murthy; Kevin Rushforth; openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial I think that the first question to answer is whether the filtering method is applied to all maps/textures of the material (diffuse, specular, self-illumination) or to each individually. I would imagine that the former makes more sense. If that's the case, the texture filtering parameter will be just one more property in PhongMaterial (perhaps in the Material supertype if it also makes sense for other possible materials - that can be figured out later in any case). On Sun, Jun 25, 2023 at 3:20?PM Matija Brown > wrote: Unfortunately it took a little longer (got busy), but have just had a quick look at the OpenGL side of things. The ES2Texture class appears to handle everything there. There are two create-Methods, but the other one is responsible for MediaFrame stuff and it doesn?t really? make sense to have non-linear filtering there? What?s your opinion? The create method seems to parse in all texture parameters simply as arguments (https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L98), it would probably be best to just add the filtering in there as well. API-wise it?s probably best to have a Texture or DiffuseMap class that the PhongMaterial uses and stores metadata about the Image. However this might be slightly overkill considering there is only this one single parameter we?re trying to add, thus maybe just a flag in PhongMaterial would suffice? Have a nice day, Matija. From: Matija Brown Sent: Thursday, 22 June 2023 18:37 To: Jayathirth Rao Daarapuram Venkatesh Murthy; Nir Lisker; Kevin Rushforth Cc: openjfx-dev at openjdk.org Subject: RE: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial I?ll do the OpenGL ? have done quite a bit with Vulkan and GL in the past so there?s no problem there. Certainly usefull if you would do some reviewing ? if you finish the Metal texture maps someone will surely find themselves to expand it with sampling. Tomorrow I?ll give a short summary on what would be to do for OpenGL, as we have that for D3D already. Then do a little example probably ? doesn?t really seem too much work to me? Thanks, Matija. From: Jayathirth Rao Daarapuram Venkatesh Murthy Sent: Thursday, 22 June 2023 06:28 To: Nir Lisker; Kevin Rushforth Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Correcting myself: Currently I am working on Metal implementation of Texture maps in JavaFX 3D : https://bugs.openjdk.org/browse/JDK-8310109 and not on adding nearest sampling(which last mail can imply). Thanks, Jay From: openjfx-dev > on behalf of Jayathirth Rao Daarapuram Venkatesh Murthy > Date: Thursday, 22 June 2023 at 9:22 AM To: Nir Lisker >, Kevin Rushforth > Cc: openjfx-dev at openjdk.org > Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Currently I am working on Metal implementation of the same and has no bandwidth to work on additional OpenGL thing. But I can help in reviewing the code if we come up with addition of nearest filtering. Thanks, Jay From: openjfx-dev > on behalf of Nir Lisker > Date: Wednesday, 21 June 2023 at 9:40 PM To: Kevin Rushforth > Cc: openjfx-dev at openjdk.org > Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial If I remember correctly, in OpenGL you parse the texture filter when the texture is being created, while in DirectX as it is bound to the sampler (it is a sampler state after all) it would have to be set before every render call. However it shouldn?t make any API difference really, as we can just have a field somewhere and the parse it along when needed. Yes, the JBS ticket mentions this difference as well. Since Kevin approved this feature and the API seems to converge nicely between the pipelines, we can start the work. I'm somewhat busy with other tasks as of late, but I will try to formulate an API. Matija or Jay, if one of you can start investigating the changes to the OpenGL pipeline we could create a branch in the sandbox repo and work there. On Wed, Jun 21, 2023 at 4:03?PM Kevin Rushforth > wrote: My preference would be to add support only for Linear and Nearest in any case. -- Kevin On 6/21/2023 4:48 AM, Matija Brown wrote: As Jayathrith said, in OpenGL as well as Metal only NEAREST and LINEAR filters are available. There might be a way of getting around it by implementing some own algorithm for OpenGL and Metal but that seem slightly over the top. So either one would have to keep the options limited to the two supported everywhere or go with the ?conditional? features. Having had a look at DirectX the APIs seem not to differ too much. If I remember correctly, in OpenGL you parse the texture filter when the texture is being created, while in DirectX as it is bound to the sampler (it is a sampler state after all) it would have to be set before every render call. However it shouldn?t make any API difference really, as we can just have a field somewhere and the parse it along when needed. Cheers, Matija. From: Jayathirth Rao Daarapuram Venkatesh Murthy Sent: Wednesday, 21 June 2023 13:09 To: Nir Lisker; Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In OpenGL we set GL_LINEAR by default at : https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L221 And Metal supports only two types of Min/Max filters : Nearest(default) and Linear. So even if D3D supports multiple types we might be limited to support only these 2 filters for all platforms. Thanks, Jay From: openjfx-dev on behalf of Nir Lisker Date: Wednesday, 21 June 2023 at 3:57 PM To: Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial First of all, please excuse directly e-mailing you earlier today. Working with mailing lists is quite new for me and apparently I forgot to add the mailing list to cc. I didn't get any private email, so you seem to be doing better than you thought with the mailing list :) With the OpenGL-side I do have some experience. Concerning the D3D-side of things it would probably mean convincing Somebody that it is a good idea to finally apply the suggested change. There would be some API change required of course. As a basic concept it would probably be sensible to add this as a parameter to the PhonMaterial-class. Alternatively it might make sense to add a ?Texture? class that is used a a DiffuseMap in the PhonMaterial. But that seems slightly overkill. Where to put the new methods in the Java side is not the concerning part, it's how to create methods that match all the pipelines. In D3D, the method for setting the filter is detailed in [1], and its possible parameters in [2][3][4]. So suppose that I'm looking at the list of available filter types there: D3DTEXF_NONE, D3DTEXF_POINT, D3DTEXF_LINEAR, D3DTEXF_ANISOTROPIC, D3DTEXF_PYRAMIDALQUAD, D3DTEXF_GAUSSIANQUAD, D3DTEXF_CONVOLUTIONMONO, if OpenGL supports a somewhat different set of filters, we will have some clashes in the Java API side. Generally, we would like to give as much flexibility to the user as possible, but need to be careful with platform-specific functionality. We could round *some* corners. For example, I think that if we have an enum for the filter types above that is a union of the ones available in the different pipelines, and if a few are supported by only one of the pipelines, we could note it in the docs and get away with it (something similar to a conditional feature). However, if the whole native pipeline setup for texture filtering is different, which means a different set of Java API methods per pipeline, then that's too much. All this means is that to continue we need to figure out what the API for each pipeline looks like, what's the most functionality we can have for each pipeline, and then how we can unite them into a single Java API with the hopes of being able to reconcile the differences "well enough" (whatever that will mean). [1] https://learn.microsoft.com/en-us/windows/win32/api/d3d9helper/nf-d3d9helper-idirect3ddevice9-setsamplerstate [2] https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dtexturefiltertype [3] https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dsamplerstatetype [4] https://learn.microsoft.com/en-us/windows/win32/direct3d9/vertex-textures-in-vs-3-0 On Wed, Jun 21, 2023 at 12:45?PM Matija Brown > wrote: First of all, please excuse directly e-mailing you earlier today. Working with mailing lists is quite new for me and apparently I forgot to add the mailing list to cc. With the OpenGL-side I do have some experience. Concerning the D3D-side of things it would probably mean convincing Somebody that it is a good idea to finally apply the suggested change. There would be some API change required of course. As a basic concept it would probably be sensible to add this as a parameter to the PhonMaterial-class. Alternatively it might make sense to add a ?Texture? class that is used a a DiffuseMap in the PhonMaterial. But that seems slightly overkill. As I am not very well acquainted with current design principles of this library, these things should lie in more experience contributors hands. From: Nir Lisker Sent: Tuesday, 20 June 2023 20:50 To: Matija Brown Cc: openjfx-dev at openjdk.org Subject: Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? There is no API to set the texture filter. If you would like to contribute and add it, I can help. It needs to be compatible with both Direct3D and OpenGL (not sure how the work on Metal is going), so this can be a challenge. For the D3D side, see this issue in JBS [1]. The relevant code is at [2]. I didn't look at the OpenGL side. - Nir [1] https://bugs.openjdk.org/browse/JDK-8092272 [2] https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc#L621 On Mon, Jun 19, 2023 at 10:15?PM Matija Brown > wrote: On my never ending journey of building a Minecraft-clone in every graphics-framework available, I have come across JavaFX for the next attempt. However a minor inconvenience has crossed my path in the process: Using the (very well developed!) 2D-Graphics displaying pixel-art style images is no trouble whatsoever. Simply rendering it to a canvas and disabling smoothing does the job just fine. Unfortunately, I have been unable to figure out how to achieve a similar thing using the 3D-Graphics engine and the PhongMaterial that comes with it. Which leads to the question; Does there, in JavaFX exist something comparable to setting the texture-sampler to NEAREST instead of LINEAR sampling? Unfortunately the latest information I could find online was from about 2013 and much has (probably) changed since then. Thus the question is being posed once again. I whish to excuse myself for probably repeating a fairly common question, Kind regards, Matija Brown. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvos at openjdk.org Mon Jun 26 13:48:10 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 26 Jun 2023 13:48:10 GMT Subject: RFR: 8310638: Filtering a TableView with a large number of items freezes the UI Message-ID: This PR fix a performance issue introduced by the fix for JDK-8306447. In that PR, we changed the behavior in case the cellcount changes. In case the cellcount changes to a lower value than the original one, we have to make sure the current index is not higher than the new amount of cells as that would lead to unnecessary computations. Fix for JDK-8310638 ------------- Commit messages: - In case the cellcount changes to a lower value, make sure the current index is not higher than Changes: https://git.openjdk.org/jfx/pull/1163/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1163&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310638 Stats: 42 lines in 3 files changed: 41 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1163.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1163/head:pull/1163 PR: https://git.openjdk.org/jfx/pull/1163 From kcr at openjdk.org Mon Jun 26 13:53:20 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 26 Jun 2023 13:53:20 GMT Subject: RFR: 8310638: Filtering a TableView with a large number of items freezes the UI In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 13:41:24 GMT, Johan Vos wrote: > This PR fix a performance issue introduced by the fix for JDK-8306447. In that PR, we changed the behavior in case the cellcount changes. In case the cellcount changes to a lower value than the original one, we have to make sure the current index is not higher than the new amount of cells as that would lead to unnecessary computations. > > Fix for JDK-8310638 I'll look at the fix and test later. I noted one change that will be needed. modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2992: > 2990: } > 2991: > 2992: protected int computeCurrentIndex() { This would make this part of the exposed public API. It looks like you are just using this for testing, so making it package scope is sufficient. Can you also add a comment that this is used for testing? ------------- Changes requested by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1163#pullrequestreview-1498577040 PR Review Comment: https://git.openjdk.org/jfx/pull/1163#discussion_r1242224815 From kcr at openjdk.org Mon Jun 26 15:08:09 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 26 Jun 2023 15:08:09 GMT Subject: RFR: 8310846: Skip failing test InitialWindowSizeTest on Linux In-Reply-To: References: Message-ID: <7CGSMC6kNvNU-Q-s8Ttuw1yURGe01Im5Y0MzJgQv5OE=.4379295d-79d5-4761-b262-9f569ab16310@github.com> On Sun, 25 Jun 2023 02:10:58 GMT, Michael Strau? wrote: > Skips `InitialWindowSizeTest` on Linux until [JDK-8310845](https://bugs.openjdk.org/browse/JDK-8310845) is fixed. This looks good, and I verified that the test is now skipped on Linux. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1162#pullrequestreview-1498773655 From kcr at openjdk.org Mon Jun 26 15:08:11 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 26 Jun 2023 15:08:11 GMT Subject: RFR: 8310846: Skip failing test InitialWindowSizeTest on Linux In-Reply-To: References: Message-ID: On Sun, 25 Jun 2023 07:59:13 GMT, Thiago Milczarek Sayao wrote: > I will try to fix it. Thanks. No hurry, though. It's been broken since JDK 8 (or earlier), and no one noticed until now. I'll assign that bug to you, but it won't be something we'll look at until after the jfx21 fork (so no earlier than jfx22). Since we will skip the failing test until it is fixed, part of the fix for that bug will be to remove the `assumeFalse` added by this PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1162#issuecomment-1607678264 From kevin.rushforth at oracle.com Mon Jun 26 15:40:30 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 26 Jun 2023 08:40:30 -0700 Subject: [External] : Re: [JavaFX 3D ( | Feature Request)] Setting Texture Nearest-Sampling on PhongMaterial In-Reply-To: References: Message-ID: Yes, but likely not until after the jfx21 fork. -- Kevin On 6/25/2023 11:03 AM, Nir Lisker wrote: > Perhaps?Jay and Kevin can weigh in on this. > > By the way, I see that the com.sun.prism.Texture interface already > defines get/setLinearFiltering methods that specify if the filtering > is not linear then it uses a nearest neighbor algorithm. It's not used > by the 3D side it seems. > > On Sun, Jun 25, 2023 at 8:54?PM Matija Brown > wrote: > > This is a good point you?re bringing up Nir! > > I?m really not sure on that. On the one hand your interpretation > seems the most sensible, but on the other hand I can?t see any use > case of NEAREST filtering in specular or self-illumination maps. > > However giving more options is also always good, and the same way > there aren?t really many places (that I?m aware of) one would have > NEAREST filtered diffuse maps and use any of the others at all. > > TLDL: Would work excellently your way API wise, but I?m not > certain if it makes sense use-case wise. > > Thanks, > > Matija. > > *From: *Nir Lisker > *Sent: *Sunday, 25 June 2023 19:49 > *To: *Matija Brown > *Cc: *Jayathirth Rao Daarapuram Venkatesh Murthy > ; Kevin Rushforth > ; openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting Texture > Nearest-Sampling on PhongMaterial > > I think that the first question to answer is whether?the filtering > method is applied to all maps/textures of the material (diffuse, > specular, self-illumination) or to each individually. I would > imagine that the former makes more sense. If that's the case, the > texture filtering parameter will be just one more property in > PhongMaterial (perhaps in the Material supertype if it also makes > sense for other possible materials - that can be figured out later > in any case). > > On Sun, Jun 25, 2023 at 3:20?PM Matija Brown > wrote: > > Unfortunately it took a little longer (got busy), but have > just had a quick look at the > > OpenGL side of things. > > The ES2Texture class appears to handle everything there. There > are two create-Methods, but the other > > one is responsible for MediaFrame stuff and it doesn?t really? > make sense to have non-linear filtering there? > > What?s your opinion? > > The create method seems to parse in all texture parameters > simply as arguments > (https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L98 > ), > > it would probably be best to just add the filtering in there > as well. > > API-wise it?s probably best to have a Texture or DiffuseMap > class that the PhongMaterial uses and stores metadata about > the Image. > > However this might be slightly overkill considering there is > only this one single parameter we?re trying to add, > > thus maybe just a flag in PhongMaterial would suffice? > > Have a nice day, > > Matija. > > *From: *Matija Brown > *Sent: *Thursday, 22 June 2023 18:37 > *To: *Jayathirth Rao Daarapuram Venkatesh Murthy > ; Nir Lisker > ; Kevin Rushforth > > *Cc: *openjfx-dev at openjdk.org > *Subject: *RE: [JavaFX 3D ( | Feature Request)] Setting > Texture Nearest-Sampling on PhongMaterial > > I?ll do the OpenGL ? have done quite a bit with Vulkan and GL > in the past so there?s no problem there. > > Certainly usefull if you would do some reviewing ? if you > finish the Metal texture maps someone will surely find > > themselves to expand it with sampling. > > Tomorrow I?ll give a short summary on what would be to do for > OpenGL, as we have that for D3D already. > > Then do a little example probably ? doesn?t really seem too > much work to me? > > Thanks, > > Matija. > > *From: *Jayathirth Rao Daarapuram Venkatesh Murthy > > *Sent: *Thursday, 22 June 2023 06:28 > *To: *Nir Lisker ; Kevin Rushforth > > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting > Texture Nearest-Sampling on PhongMaterial > > Correcting myself: > > Currently I am working on Metal implementation of Texture maps > in JavaFX 3D : https://bugs.openjdk.org/browse/JDK-8310109 and > not on adding nearest sampling(which last mail can imply). > > Thanks, > > Jay > > *From: *openjfx-dev on behalf > of Jayathirth Rao Daarapuram Venkatesh Murthy > > *Date: *Thursday, 22 June 2023 at 9:22 AM > *To: *Nir Lisker , Kevin Rushforth > > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting > Texture Nearest-Sampling on PhongMaterial > > Currently I am working on Metal implementation of the same and > has no bandwidth to work on additional OpenGL thing. > > But I can help in reviewing the code if we come up with > addition of nearest filtering. > > Thanks, > > Jay > > *From: *openjfx-dev on behalf > of Nir Lisker > *Date: *Wednesday, 21 June 2023 at 9:40 PM > *To: *Kevin Rushforth > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] Setting > Texture Nearest-Sampling on PhongMaterial > > If I remember correctly, in OpenGL you parse the texture > filter when the texture is being created, while in DirectX > as it is bound > > to the sampler (it is a sampler state after all) it would > have to be set before every render call. However it > shouldn?t make any > > API difference really, as we can just have a field > somewhere and the parse it along when needed. > > Yes, the JBS ticket mentions this difference as well. > > Since Kevin approved this feature and the API seems to > converge nicely between the pipelines, we can start the work. > I'm somewhat busy with other tasks as of late, but I will try > to formulate an API. Matija or Jay, if one of you can start > investigating the changes to the OpenGL pipeline we could > create a branch in the sandbox repo and work there. > > On Wed, Jun 21, 2023 at 4:03?PM Kevin Rushforth > wrote: > > My preference would be to add support only for Linear and > Nearest in any case. > > -- Kevin > > On 6/21/2023 4:48 AM, Matija Brown wrote: > > As Jayathrith said, in OpenGL as well as Metal only > NEAREST and LINEAR filters are available. > > There might be a way of getting around it by > implementing some own algorithm for OpenGL and Metal > but that seem slightly > > over the top. So either one would have to keep the > options limited to the two supported everywhere > > or go with the ?conditional? features. > > Having had a look at DirectX the APIs seem not to > differ too much. > > If I remember correctly, in OpenGL you parse the > texture filter when the texture is being created, > while in DirectX as it is bound > > to the sampler (it is a sampler state after all) it > would have to be set before every render call. However > it shouldn?t make any > > API difference really, as we can just have a field > somewhere and the parse it along when needed. > > Cheers, > > Matija. > > *From: *Jayathirth Rao Daarapuram Venkatesh Murthy > > *Sent: *Wednesday, 21 June 2023 13:09 > *To: *Nir Lisker ; Matija > Brown > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] > Setting Texture Nearest-Sampling on PhongMaterial > > In OpenGL we set GL_LINEAR by default at : > https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Texture.java#L221 > > > And Metal supports only two types of Min/Max filters : > Nearest(default) and Linear. So even if D3D supports > multiple types we might be limited to support only > these 2 filters for all platforms. > > Thanks, > > Jay > > *From: *openjfx-dev > on behalf of Nir > Lisker > *Date: *Wednesday, 21 June 2023 at 3:57 PM > *To: *Matija Brown > > *Cc: *openjfx-dev at openjdk.org > > *Subject: *Re: [JavaFX 3D ( | Feature Request)] > Setting Texture Nearest-Sampling on PhongMaterial > > First of all, please excuse directly e-mailing you > earlier today. Working with mailing lists is quite > new for me and apparently I forgot to add > > the mailing list to cc. > > I didn't get any private email, so you seem to be > doing better than you thought with the mailing list :) > > With the OpenGL-side I do have some experience. > Concerning the D3D-side of things it would > probably mean convincing > > Somebody that it is a good idea to finally apply > the suggested change. > > There would be some API change required of course. > As a basic concept it would probably be sensible > to add this as a parameter to the PhonMaterial-class. > > Alternatively it might make sense to add a > ?Texture? class that is used a a DiffuseMap in the > PhonMaterial. But that seems slightly overkill. > > Where to put the new methods in the Java side is not > the concerning?part, it's how to create methods that > match all the?pipelines. In D3D, the method for > setting the filter is detailed in [1], and its > possible parameters in [2][3][4]. So suppose that I'm > looking at the list of available filter types there: > > D3DTEXF_NONE, D3DTEXF_POINT, D3DTEXF_LINEAR, > D3DTEXF_ANISOTROPIC, D3DTEXF_PYRAMIDALQUAD, > D3DTEXF_GAUSSIANQUAD, D3DTEXF_CONVOLUTIONMONO, > > if OpenGL supports a somewhat different set of > filters, we will have some clashes in the Java API side. > > Generally, we would like to give as much flexibility > to the user as possible, but need to be careful > with?platform-specific functionality. We could round > *some* corners. For example, I think that if we have > an enum for the filter types above that is a union of > the ones available in the different pipelines, and if > a few are supported by only one of the pipelines, we > could note it in the docs and get away with it > (something similar to a conditional feature). However, > if the whole native pipeline setup for texture > filtering is different, which means a different set of > Java API methods per pipeline, then that's too much. > > All this means is that to continue we need to figure > out what the API for each pipeline looks like, what's > the most functionality we can have for each pipeline, > and then how we can unite them into a single Java API > with the hopes of being able to reconcile the > differences "well?enough" (whatever that will mean). > > [1] > https://learn.microsoft.com/en-us/windows/win32/api/d3d9helper/nf-d3d9helper-idirect3ddevice9-setsamplerstate > > > [2] > https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dtexturefiltertype > > > [3] > https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dsamplerstatetype > > > [4] > https://learn.microsoft.com/en-us/windows/win32/direct3d9/vertex-textures-in-vs-3-0 > > > On Wed, Jun 21, 2023 at 12:45?PM Matija Brown > wrote: > > First of all, please excuse directly e-mailing you > earlier today. Working with mailing lists is quite > new for me and apparently I forgot to add > > the mailing list to cc. > > With the OpenGL-side I do have some experience. > Concerning the D3D-side of things it would > probably mean convincing > > Somebody that it is a good idea to finally apply > the suggested change. > > There would be some API change required of course. > As a basic concept it would probably be sensible > to add this as a parameter to the PhonMaterial-class. > > Alternatively it might make sense to add a > ?Texture? class that is used a a DiffuseMap in the > PhonMaterial. But that seems slightly overkill. > > As I am not very well acquainted with current > design principles of this library, these things > should lie in more experience contributors hands. > > *From: *Nir Lisker > *Sent: *Tuesday, 20 June 2023 20:50 > *To: *Matija Brown > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [JavaFX 3D ( | Feature Request)] > Setting Texture Nearest-Sampling on PhongMaterial > > Which leads to the question; Does there, in > JavaFX exist something comparable to setting > the texture-sampler to NEAREST > > instead of LINEAR sampling? > > There is no API to set the texture filter. If you > would like to contribute and add it, I can help. > It needs to be compatible with both Direct3D and > OpenGL (not sure how the work on Metal is going), > so this can be a challenge. > > For the?D3D side, see this issue in JBS [1]. The > relevant code is at [2]. I didn't look at the > OpenGL side. > > - Nir > > [1] https://bugs.openjdk.org/browse/JDK-8092272 > > [2] > https://github.com/openjdk/jfx/blob/0d9dcf38275528e1b621d71631aac5bdb9452110/modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc#L621 > > > On Mon, Jun 19, 2023 at 10:15?PM Matija Brown > wrote: > > On my never ending journey of building a > Minecraft-clone in every graphics-framework > available, > > I have come across JavaFX for the next attempt. > > However a minor inconvenience has crossed my > path in the process: > > Using the (very well developed!) 2D-Graphics > displaying pixel-art style images is no > trouble whatsoever. > > Simply rendering it to a canvas and disabling > smoothing does the job just fine. > Unfortunately, I have been > > unable to figure out how to achieve a similar > thing using the 3D-Graphics engine and the > PhongMaterial that comes with it. > > Which leads to the question; Does there, in > JavaFX exist something comparable to setting > the texture-sampler to NEAREST > > instead of LINEAR sampling? > > Unfortunately the latest information I could > find online was from about 2013 and much has > (probably) > > changed since then. Thus the question is being > posed once again. > > I whish to excuse myself for probably > repeating a fairly common question, > > Kind regards, > Matija Brown. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Mon Jun 26 16:40:12 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 26 Jun 2023 16:40:12 GMT Subject: Integrated: 8310846: Skip failing test InitialWindowSizeTest on Linux In-Reply-To: References: Message-ID: <_P5yrfMnHHP3n3QPpS0jM9NXFMO5Z-cGwvLXxpGVTY0=.ad716c73-2f1f-4cee-827b-fee8e813b88b@github.com> On Sun, 25 Jun 2023 02:10:58 GMT, Michael Strau? wrote: > Skips `InitialWindowSizeTest` on Linux until [JDK-8310845](https://bugs.openjdk.org/browse/JDK-8310845) is fixed. This pull request has now been integrated. Changeset: d010d41c Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/d010d41cc9519a792957c6dda8275757b4664704 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8310846: Skip failing test InitialWindowSizeTest on Linux Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1162 From jvos at openjdk.org Mon Jun 26 17:11:26 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 26 Jun 2023 17:11:26 GMT Subject: RFR: 8310638: Filtering a TableView with a large number of items freezes the UI [v2] In-Reply-To: References: Message-ID: > This PR fix a performance issue introduced by the fix for JDK-8306447. In that PR, we changed the behavior in case the cellcount changes. In case the cellcount changes to a lower value than the original one, we have to make sure the current index is not higher than the new amount of cells as that would lead to unnecessary computations. > > Fix for JDK-8310638 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: change access to package scope ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1163/files - new: https://git.openjdk.org/jfx/pull/1163/files/eea57362..6b4ed092 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1163&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1163&range=00-01 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1163.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1163/head:pull/1163 PR: https://git.openjdk.org/jfx/pull/1163 From angorya at openjdk.org Mon Jun 26 20:00:10 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 26 Jun 2023 20:00:10 GMT Subject: RFR: 8310638: Filtering a TableView with a large number of items freezes the UI [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 17:11:26 GMT, Johan Vos wrote: >> This PR fix a performance issue introduced by the fix for JDK-8306447. In that PR, we changed the behavior in case the cellcount changes. In case the cellcount changes to a lower value than the original one, we have to make sure the current index is not higher than the new amount of cells as that would lead to unnecessary computations. >> >> Fix for JDK-8310638 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > change access to package scope Tested with the Monkey Tester https://github.com/andy-goryachev-oracle/MonkeyTest see no ill effects. modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 861: > 859: double oldOffset = computeViewportOffset(getPosition(), oldCount); > 860: int cellCount = get(); > 861: if (oldIndex > cellCount) oldIndex = cellCount; minor: add { }'s ? ------------- PR Review: https://git.openjdk.org/jfx/pull/1163#pullrequestreview-1499306492 PR Review Comment: https://git.openjdk.org/jfx/pull/1163#discussion_r1242691904 From kcr at openjdk.org Mon Jun 26 22:01:13 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 26 Jun 2023 22:01:13 GMT Subject: RFR: 8310638: Filtering a TableView with a large number of items freezes the UI [v2] In-Reply-To: References: Message-ID: <0T7pSrmDT96Bwg84wLVP540_AhQpxfS5uk7tnzIHmrI=.ec1d64df-56f7-478f-81a4-021d479abe83@github.com> On Mon, 26 Jun 2023 17:11:26 GMT, Johan Vos wrote: >> This PR fix a performance issue introduced by the fix for JDK-8306447. In that PR, we changed the behavior in case the cellcount changes. In case the cellcount changes to a lower value than the original one, we have to make sure the current index is not higher than the new amount of cells as that would lead to unnecessary computations. >> >> Fix for JDK-8310638 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > change access to package scope The change and explanation looks good to me. I confirm that the newly added test fails without the fix and passes with the fix. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1163#pullrequestreview-1499558851 From jhendrikx at openjdk.org Tue Jun 27 12:13:13 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 27 Jun 2023 12:13:13 GMT Subject: RFR: 8310638: Filtering a TableView with a large number of items freezes the UI [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 17:11:26 GMT, Johan Vos wrote: >> This PR fix a performance issue introduced by the fix for JDK-8306447. In that PR, we changed the behavior in case the cellcount changes. In case the cellcount changes to a lower value than the original one, we have to make sure the current index is not higher than the new amount of cells as that would lead to unnecessary computations. >> >> Fix for JDK-8310638 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > change access to package scope Marked as reviewed by jhendrikx (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1163#pullrequestreview-1500703395 From kpk at openjdk.org Tue Jun 27 15:30:39 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 27 Jun 2023 15:30:39 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow [v2] In-Reply-To: References: Message-ID: > The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when Text node was embedded in TextFlow. Hence wrong character index value was calculated for the same. > > Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index. > > Added tests to validate the changes. Karthik P K has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Resolve merge conflict - Fix character index calculation issue in Text node embedded in TextFlow ------------- Changes: https://git.openjdk.org/jfx/pull/1157/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1157&range=01 Stats: 372 lines in 7 files changed: 358 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1157.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1157/head:pull/1157 PR: https://git.openjdk.org/jfx/pull/1157 From kpk at openjdk.org Tue Jun 27 16:06:18 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 27 Jun 2023 16:06:18 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow [v3] In-Reply-To: References: Message-ID: > The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when Text node was embedded in TextFlow. Hence wrong character index value was calculated for the same. > > Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index. > > Added tests to validate the changes. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Fix issue with wrapped text ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1157/files - new: https://git.openjdk.org/jfx/pull/1157/files/0b515d8e..c7eac8ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1157&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1157&range=01-02 Stats: 145 lines in 2 files changed: 138 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1157.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1157/head:pull/1157 PR: https://git.openjdk.org/jfx/pull/1157 From kpk at openjdk.org Tue Jun 27 16:06:20 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 27 Jun 2023 16:06:20 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023 15:30:39 GMT, Karthik P K wrote: >> The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when Text node was embedded in TextFlow. Hence wrong character index value was calculated for the same. >> >> Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index. >> >> Added tests to validate the changes. > > Karthik P K has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Resolve merge conflict > - Fix character index calculation issue in Text node embedded in TextFlow Fixed issue with wrapped text. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1609815252 From angorya at openjdk.org Tue Jun 27 16:15:16 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 27 Jun 2023 16:15:16 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow [v3] In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023 16:06:18 GMT, Karthik P K wrote: >> The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when Text node was embedded in TextFlow. Hence wrong character index value was calculated for the same. >> >> Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index. >> >> Added tests to validate the changes. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Fix issue with wrapped text does not seem to work right still - if you arrange the split panes to make the emoji wrap (see the next screenshot), I think not only it shows incorrect insertion index when you move the mouse across that emoji (in Text.hitTest goes from 0 to 1, while expected change is 2), but I think it's also wrong because that emoji is the last symbol in that Text instance, so insertion index should be different (larger). Are you reporting insertion index relative to the Text's text or TextRun? ![Screenshot 2023-06-27 at 09 07 30](https://github.com/openjdk/jfx/assets/107069028/08836b3b-c795-4b1d-803a-c0589141c9bf) ![Screenshot 2023-06-27 at 09 07 36](https://github.com/openjdk/jfx/assets/107069028/2f055077-fd04-42e8-bd4b-9c60f41c59a0) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1609834407 From kpk at openjdk.org Tue Jun 27 17:52:14 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 27 Jun 2023 17:52:14 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow [v3] In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023 16:13:03 GMT, Andy Goryachev wrote: > I think not only it shows incorrect insertion index when you move the mouse across that emoji (in Text.hitTest goes from 0 to 1, while expected change is 2), but I think it's also wrong because that emoji is the last symbol in that Text instance, so insertion index should be different (larger). Looks like the wrong insertion index is getting reported after 2nd line. I'll fix this issue. >Are you reporting insertion index relative to the Text's text or TextRun? The insertion index is reported relative to the Text's text incase of Text node. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1609967354 From angorya at openjdk.org Tue Jun 27 17:59:12 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 27 Jun 2023 17:59:12 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow [v3] In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023 17:49:48 GMT, Karthik P K wrote: > The insertion index is reported relative to the Text's text incase of Text node. right. in the case of the (highlighted) emoji character - the insertion index starts with 0 which I think cannot be correct, because all of the text should be added as a single Text instance, see https://github.com/andy-goryachev-oracle/MonkeyTest/blob/e361b7800b5497da5e23a7eda26084e800410f38/src/com/oracle/tools/fx/monkey/util/Templates.java#L60 and https://github.com/andy-goryachev-oracle/MonkeyTest/blob/e361b7800b5497da5e23a7eda26084e800410f38/src/com/oracle/tools/fx/monkey/pages/TextFlowPage.java#L208 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1609975167 From jvos at openjdk.org Tue Jun 27 18:02:33 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 27 Jun 2023 18:02:33 GMT Subject: RFR: 8310638: Filtering a TableView with a large number of items freezes the UI [v3] In-Reply-To: References: Message-ID: <9ecX1EPL30CDtsJ1jLakbjo1ce2pGE6GtJjStDdlH4E=.cc7710fe-3e3e-41f5-bdcc-3765932426ba@github.com> > This PR fix a performance issue introduced by the fix for JDK-8306447. In that PR, we changed the behavior in case the cellcount changes. In case the cellcount changes to a lower value than the original one, we have to make sure the current index is not higher than the new amount of cells as that would lead to unnecessary computations. > > Fix for JDK-8310638 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Address reviewer comment ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1163/files - new: https://git.openjdk.org/jfx/pull/1163/files/6b4ed092..9d3f21a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1163&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1163&range=01-02 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1163.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1163/head:pull/1163 PR: https://git.openjdk.org/jfx/pull/1163 From angorya at openjdk.org Tue Jun 27 18:02:33 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 27 Jun 2023 18:02:33 GMT Subject: RFR: 8310638: Filtering a TableView with a large number of items freezes the UI [v3] In-Reply-To: <9ecX1EPL30CDtsJ1jLakbjo1ce2pGE6GtJjStDdlH4E=.cc7710fe-3e3e-41f5-bdcc-3765932426ba@github.com> References: <9ecX1EPL30CDtsJ1jLakbjo1ce2pGE6GtJjStDdlH4E=.cc7710fe-3e3e-41f5-bdcc-3765932426ba@github.com> Message-ID: On Tue, 27 Jun 2023 17:57:20 GMT, Johan Vos wrote: >> This PR fix a performance issue introduced by the fix for JDK-8306447. In that PR, we changed the behavior in case the cellcount changes. In case the cellcount changes to a lower value than the original one, we have to make sure the current index is not higher than the new amount of cells as that would lead to unnecessary computations. >> >> Fix for JDK-8310638 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Address reviewer comment thank you! (sorry, last commit due to my comment invalidated two prior approvals) ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1163#pullrequestreview-1501551593 From kcr at openjdk.org Tue Jun 27 18:18:10 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 27 Jun 2023 18:18:10 GMT Subject: RFR: 8310638: Filtering a TableView with a large number of items freezes the UI [v3] In-Reply-To: <9ecX1EPL30CDtsJ1jLakbjo1ce2pGE6GtJjStDdlH4E=.cc7710fe-3e3e-41f5-bdcc-3765932426ba@github.com> References: <9ecX1EPL30CDtsJ1jLakbjo1ce2pGE6GtJjStDdlH4E=.cc7710fe-3e3e-41f5-bdcc-3765932426ba@github.com> Message-ID: <-mdcPuuumz0bmzKkD2kLuLQtlbGJaEnrnd6PpnmP32g=.8f2e406b-2d46-4d13-97ab-febe7985b598@github.com> On Tue, 27 Jun 2023 18:02:33 GMT, Johan Vos wrote: >> This PR fix a performance issue introduced by the fix for JDK-8306447. In that PR, we changed the behavior in case the cellcount changes. In case the cellcount changes to a lower value than the original one, we have to make sure the current index is not higher than the new amount of cells as that would lead to unnecessary computations. >> >> Fix for JDK-8310638 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Address reviewer comment Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1163#pullrequestreview-1501586129 From jvos at openjdk.org Tue Jun 27 18:24:11 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 27 Jun 2023 18:24:11 GMT Subject: Integrated: 8310638: Filtering a TableView with a large number of items freezes the UI In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 13:41:24 GMT, Johan Vos wrote: > This PR fix a performance issue introduced by the fix for JDK-8306447. In that PR, we changed the behavior in case the cellcount changes. In case the cellcount changes to a lower value than the original one, we have to make sure the current index is not higher than the new amount of cells as that would lead to unnecessary computations. > > Fix for JDK-8310638 This pull request has now been integrated. Changeset: 8b1a446c Author: Johan Vos URL: https://git.openjdk.org/jfx/commit/8b1a446ca9519f468aa1cf6ee9876b6035dcac37 Stats: 48 lines in 3 files changed: 47 ins; 0 del; 1 mod 8310638: Filtering a TableView with a large number of items freezes the UI Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1163 From angorya at openjdk.org Tue Jun 27 18:26:13 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 27 Jun 2023 18:26:13 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v2] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: On Fri, 23 Jun 2023 15:45:21 GMT, Andy Goryachev wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale) (I think). > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments @hjohn would you mind taking a look at this? using the ideas from your SpaceDistributor ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1610013011 From angorya at openjdk.org Tue Jun 27 18:46:12 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 27 Jun 2023 18:46:12 GMT Subject: RFR: 8283551: ControlAcceleratorSupport menu items listener causes memory leak [v2] In-Reply-To: References: Message-ID: On Fri, 24 Feb 2023 10:04:48 GMT, Dean Wookey wrote: >> Each time a menu would change scenes, a new set of ListChangeListeners would be added to the items in the menu. The bigger problem however is that these list change listeners have a strong reference to the scene which is potentially a much bigger leak. >> >> The first commit was more straightforward, but there are 2 things that might be of concern: >> >> 1. The method removeAcceleratorsFromScene takes in a scene parameter, but it'll remove all the ListChangeListeners attached to it, regardless of which scene was passed in. Something similar happens with changeListenerMap already, so I think it's fine. >> 2. I made the remove method public so that external calls from skins to remove the accelerators would remove the ListChangeListener and also because all the remove methods are public. >> >> After I wrote more tests I realised using the ObservableLists as keys in the WeakHashMaps was a bad idea. If Java had a WeakIdentityHashMap the fix would be simple. The fix is in the second commit. >> >> There are still more issues that stem from the fact that for each anchor there could be multiple menus and the current code doesn't account for that. For example, swapping context menus on a tab doesn't register change listeners on the new context menu because the TabPane itself had a scene change listener already. These other issues could relate to JDK-8268374 https://bugs.openjdk.org/browse/JDK-8268374 and JDK-8283449 https://bugs.openjdk.org/browse/JDK-8283449. One of the issues is related to the fact that there's no logic to remove listeners when Tab/TableColumn's are removed from their associated control (TabPane, TableView, TreeTableView). >> >> I'm looking at these issues, but I think they're dependent on this fix. Either I can add to this PR or I can wait to see what comes out of this and fix them subsequently. > > Dean Wookey has updated the pull request incrementally with one additional commit since the last revision: > > Added more comments and fixed IdentityWrapper hashcode. is this ready to go? i think it's waiting for slash-integrate command... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1037#issuecomment-1610039298 From kcr at openjdk.org Tue Jun 27 19:18:12 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 27 Jun 2023 19:18:12 GMT Subject: RFR: 8283551: ControlAcceleratorSupport menu items listener causes memory leak [v2] In-Reply-To: References: Message-ID: On Fri, 24 Feb 2023 10:04:48 GMT, Dean Wookey wrote: >> Each time a menu would change scenes, a new set of ListChangeListeners would be added to the items in the menu. The bigger problem however is that these list change listeners have a strong reference to the scene which is potentially a much bigger leak. >> >> The first commit was more straightforward, but there are 2 things that might be of concern: >> >> 1. The method removeAcceleratorsFromScene takes in a scene parameter, but it'll remove all the ListChangeListeners attached to it, regardless of which scene was passed in. Something similar happens with changeListenerMap already, so I think it's fine. >> 2. I made the remove method public so that external calls from skins to remove the accelerators would remove the ListChangeListener and also because all the remove methods are public. >> >> After I wrote more tests I realised using the ObservableLists as keys in the WeakHashMaps was a bad idea. If Java had a WeakIdentityHashMap the fix would be simple. The fix is in the second commit. >> >> There are still more issues that stem from the fact that for each anchor there could be multiple menus and the current code doesn't account for that. For example, swapping context menus on a tab doesn't register change listeners on the new context menu because the TabPane itself had a scene change listener already. These other issues could relate to JDK-8268374 https://bugs.openjdk.org/browse/JDK-8268374 and JDK-8283449 https://bugs.openjdk.org/browse/JDK-8283449. One of the issues is related to the fact that there's no logic to remove listeners when Tab/TableColumn's are removed from their associated control (TabPane, TableView, TreeTableView). >> >> I'm looking at these issues, but I think they're dependent on this fix. Either I can add to this PR or I can wait to see what comes out of this and fix them subsequently. > > Dean Wookey has updated the pull request incrementally with one additional commit since the last revision: > > Added more comments and fixed IdentityWrapper hashcode. @arapte I believe that you still wanted take a look at this. Can you please confirm? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1037#issuecomment-1610081146 From kpk at openjdk.org Wed Jun 28 05:27:18 2023 From: kpk at openjdk.org (Karthik P K) Date: Wed, 28 Jun 2023 05:27:18 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow [v3] In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023 17:56:09 GMT, Andy Goryachev wrote: > right. in the case of the (highlighted) emoji character - the insertion index starts with 0 which I think cannot be correct, because all of the text should be added as a single Text instance, see > If a Text node's content is wrapped, then character index will start from 0 again in the new line or do we expect it to be relative to text node and continue with character index from previous line? If the latter behavior is expected then I couldn't find a way to differentiate between a text node which is wrapped and which is not. Even if warp information is available, the `getOffsetAtX` method returns the offset (character index) based on the x coordinate value which is relative to the new line. If we use run's start value along with the offset, then we get absolute value of character index relative to textflow. So it looks to me that if a Text node's content is wrapped, then character index in the new line will start from 0. In this case insertion index starting from 0 looks to be correct. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1610759317 From arapte at openjdk.org Wed Jun 28 06:28:13 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 28 Jun 2023 06:28:13 GMT Subject: RFR: 8283551: ControlAcceleratorSupport menu items listener causes memory leak [v2] In-Reply-To: References: Message-ID: On Fri, 24 Feb 2023 10:04:48 GMT, Dean Wookey wrote: >> Each time a menu would change scenes, a new set of ListChangeListeners would be added to the items in the menu. The bigger problem however is that these list change listeners have a strong reference to the scene which is potentially a much bigger leak. >> >> The first commit was more straightforward, but there are 2 things that might be of concern: >> >> 1. The method removeAcceleratorsFromScene takes in a scene parameter, but it'll remove all the ListChangeListeners attached to it, regardless of which scene was passed in. Something similar happens with changeListenerMap already, so I think it's fine. >> 2. I made the remove method public so that external calls from skins to remove the accelerators would remove the ListChangeListener and also because all the remove methods are public. >> >> After I wrote more tests I realised using the ObservableLists as keys in the WeakHashMaps was a bad idea. If Java had a WeakIdentityHashMap the fix would be simple. The fix is in the second commit. >> >> There are still more issues that stem from the fact that for each anchor there could be multiple menus and the current code doesn't account for that. For example, swapping context menus on a tab doesn't register change listeners on the new context menu because the TabPane itself had a scene change listener already. These other issues could relate to JDK-8268374 https://bugs.openjdk.org/browse/JDK-8268374 and JDK-8283449 https://bugs.openjdk.org/browse/JDK-8283449. One of the issues is related to the fact that there's no logic to remove listeners when Tab/TableColumn's are removed from their associated control (TabPane, TableView, TreeTableView). >> >> I'm looking at these issues, but I think they're dependent on this fix. Either I can add to this PR or I can wait to see what comes out of this and fix them subsequently. > > Dean Wookey has updated the pull request incrementally with one additional commit since the last revision: > > Added more comments and fixed IdentityWrapper hashcode. Apologies for the delay. This looks good to me. Have no comments. please integrate. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1037#issuecomment-1610827994 From arapte at openjdk.org Wed Jun 28 06:40:11 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 28 Jun 2023 06:40:11 GMT Subject: RFR: 8310847: [Mac] Silence OpenGL deprecation warnings In-Reply-To: <9rhhdkuWDLGtqn3jAaIhtDUt0a9NmGzeZ4eyu1Xd5Hc=.d5260a95-32b2-430b-b9e3-d1c0b6e4417e@github.com> References: <9rhhdkuWDLGtqn3jAaIhtDUt0a9NmGzeZ4eyu1Xd5Hc=.d5260a95-32b2-430b-b9e3-d1c0b6e4417e@github.com> Message-ID: On Sat, 24 Jun 2023 17:53:31 GMT, Martin Fox wrote: > The Mac build issues a lot of warnings including several related to the deprecation of OpenGL in macOS 10.14. Now that the deployment target for JavaFX is 11.0 across the board these warnings are showing up on both M1 and Intel builds. Luckily Apple provides a simply way to silence these warnings by setting a single C preprocessor define. All the OpenGL warnings get silenced except following two: 1. modules/javafx.graphics/src/main/native-prism-es2/macosx/MacOSXWindowSystemInterface.m:120:24: warning: 'setView:' is deprecated: first deprecated in macOS 10.14 - Use NSOpenGLView to provide OpenGL content in a Cocoa app. [-Wdeprecated-declarations] 2. modules/javafx.graphics/src/main/native-prism-es2/macosx/MacOSXWindowSystemInterface.m:181:57: warning: 'NSOpenGLCPSwapInterval' is deprecated: first deprecated in macOS 10.14 [-Wdeprecated-declarations] Could you please take a look why are these not silenced. Otherwise looks good. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1161#issuecomment-1610849998 From arapte at openjdk.org Wed Jun 28 06:47:10 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 28 Jun 2023 06:47:10 GMT Subject: RFR: 8310847: [Mac] Silence OpenGL deprecation warnings In-Reply-To: <9rhhdkuWDLGtqn3jAaIhtDUt0a9NmGzeZ4eyu1Xd5Hc=.d5260a95-32b2-430b-b9e3-d1c0b6e4417e@github.com> References: <9rhhdkuWDLGtqn3jAaIhtDUt0a9NmGzeZ4eyu1Xd5Hc=.d5260a95-32b2-430b-b9e3-d1c0b6e4417e@github.com> Message-ID: On Sat, 24 Jun 2023 17:53:31 GMT, Martin Fox wrote: > The Mac build issues a lot of warnings including several related to the deprecation of OpenGL in macOS 10.14. Now that the deployment target for JavaFX is 11.0 across the board these warnings are showing up on both M1 and Intel builds. Luckily Apple provides a simply way to silence these warnings by setting a single C preprocessor define. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1161#pullrequestreview-1502392502 From dwookey at openjdk.org Wed Jun 28 07:01:15 2023 From: dwookey at openjdk.org (Dean Wookey) Date: Wed, 28 Jun 2023 07:01:15 GMT Subject: Integrated: 8283551: ControlAcceleratorSupport menu items listener causes memory leak In-Reply-To: References: Message-ID: On Thu, 16 Feb 2023 15:15:11 GMT, Dean Wookey wrote: > Each time a menu would change scenes, a new set of ListChangeListeners would be added to the items in the menu. The bigger problem however is that these list change listeners have a strong reference to the scene which is potentially a much bigger leak. > > The first commit was more straightforward, but there are 2 things that might be of concern: > > 1. The method removeAcceleratorsFromScene takes in a scene parameter, but it'll remove all the ListChangeListeners attached to it, regardless of which scene was passed in. Something similar happens with changeListenerMap already, so I think it's fine. > 2. I made the remove method public so that external calls from skins to remove the accelerators would remove the ListChangeListener and also because all the remove methods are public. > > After I wrote more tests I realised using the ObservableLists as keys in the WeakHashMaps was a bad idea. If Java had a WeakIdentityHashMap the fix would be simple. The fix is in the second commit. > > There are still more issues that stem from the fact that for each anchor there could be multiple menus and the current code doesn't account for that. For example, swapping context menus on a tab doesn't register change listeners on the new context menu because the TabPane itself had a scene change listener already. These other issues could relate to JDK-8268374 https://bugs.openjdk.org/browse/JDK-8268374 and JDK-8283449 https://bugs.openjdk.org/browse/JDK-8283449. One of the issues is related to the fact that there's no logic to remove listeners when Tab/TableColumn's are removed from their associated control (TabPane, TableView, TreeTableView). > > I'm looking at these issues, but I think they're dependent on this fix. Either I can add to this PR or I can wait to see what comes out of this and fix them subsequently. This pull request has now been integrated. Changeset: 8fd2943c Author: Dean Wookey Committer: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/8fd2943c52cb47ec247ce0e6657afdc9bdc725ae Stats: 426 lines in 4 files changed: 406 ins; 1 del; 19 mod 8283551: ControlAcceleratorSupport menu items listener causes memory leak Reviewed-by: angorya, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/1037 From kcr at openjdk.org Wed Jun 28 15:10:09 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Jun 2023 15:10:09 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v2] In-Reply-To: <0hH8-9k1R9vTiRnukBMBjkt3UxspriLXm82KpDp8O9Q=.d96da3b6-6efc-41d4-bd5c-11af61f1256b@github.com> References: <1ybACQTFTQ4PqtoPyikEJ0WM0i6p-Sou3BOBKOpCrrA=.fdfe08aa-9458-4e6b-a099-2331a89bf951@github.com> <0hH8-9k1R9vTiRnukBMBjkt3UxspriLXm82KpDp8O9Q=.d96da3b6-6efc-41d4-bd5c-11af61f1256b@github.com> Message-ID: <1C7nRZSxHigJbFU6nLiU951oR3iRp-dzF5t1R1ZGF_Y=.5440cce4-2712-4e4b-944d-6c2128b97676@github.com> On Sat, 24 Jun 2023 19:23:10 GMT, Michael Strau? wrote: > My suggestion is to have the following new operations: > > * `subscribe` (`Runnable`, `Consumer`, `BiConsumer`) This seems reasonable. I could be talked into the longer names, but I prefer the overloaded `subscribe` name. > * `subscribeListener` (`InvalidationListener`, `ChangeListener`) This might be a useful follow-on Enhancement, but I wouldn't do it as part of this one. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1245370743 From jhendrikx at openjdk.org Wed Jun 28 15:10:19 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 28 Jun 2023 15:10:19 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v2] In-Reply-To: <1C7nRZSxHigJbFU6nLiU951oR3iRp-dzF5t1R1ZGF_Y=.5440cce4-2712-4e4b-944d-6c2128b97676@github.com> References: <1ybACQTFTQ4PqtoPyikEJ0WM0i6p-Sou3BOBKOpCrrA=.fdfe08aa-9458-4e6b-a099-2331a89bf951@github.com> <0hH8-9k1R9vTiRnukBMBjkt3UxspriLXm82KpDp8O9Q=.d96da3b6-6efc-41d4-bd5c-11af61f1256b@github.com> <1C7nRZSxHigJbFU6nLiU951oR3iRp-dzF5t1R1ZGF_Y=.5440cce4-2712-4e4b-944d-6c2128b97676@github.com> Message-ID: <3N9jbm3k-QZKwMYL6uqzLTauubbyUmv-i13-rcKzcak=.01deb591-7e04-4e0d-86de-e94884ae344b@github.com> On Wed, 28 Jun 2023 15:02:22 GMT, Kevin Rushforth wrote: >> I prefer `subscribe` with overloads, as this comes closest to the existing naming scheme of JavaFX listener operations (`addListener` / `removeListener` with overloads). >> >> I would also like to see a subscription-style API that works with the existing listener types. This has the advantage of not needing a wrapper for each listener registration, and it can be a drop-in replacement in many places where JavaFX listeners are used today. >> >> My suggestion is to have the following new operations: >> * `subscribe` (`Runnable`, `Consumer`, `BiConsumer`) >> * `subscribeListener` (`InvalidationListener`, `ChangeListener`) >> >> This pairs nicely with the existing operations: >> * `addListener` (`InvalidationListener`, `ChangeListener`) >> * `removeListener` (`InvalidationListener`, `ChangeListener`) > >> My suggestion is to have the following new operations: >> >> * `subscribe` (`Runnable`, `Consumer`, `BiConsumer`) > > This seems reasonable. I could be talked into the longer names, but I prefer the overloaded `subscribe` name. > >> * `subscribeListener` (`InvalidationListener`, `ChangeListener`) > > This might be a useful follow-on Enhancement, but I wouldn't do it as part of this one. I prefer short names here as often there will be a lambda or method reference following it that makes it clear what you're doing, so I guess that's a vote for `subscribe` plus overrides then. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1245374847 From duke at openjdk.org Wed Jun 28 18:23:18 2023 From: duke at openjdk.org (Martin Fox) Date: Wed, 28 Jun 2023 18:23:18 GMT Subject: RFR: 8310847: [Mac] Silence OpenGL deprecation warnings [v2] In-Reply-To: <9rhhdkuWDLGtqn3jAaIhtDUt0a9NmGzeZ4eyu1Xd5Hc=.d5260a95-32b2-430b-b9e3-d1c0b6e4417e@github.com> References: <9rhhdkuWDLGtqn3jAaIhtDUt0a9NmGzeZ4eyu1Xd5Hc=.d5260a95-32b2-430b-b9e3-d1c0b6e4417e@github.com> Message-ID: > The Mac build issues a lot of warnings including several related to the deprecation of OpenGL in macOS 10.14. Now that the deployment target for JavaFX is 11.0 across the board these warnings are showing up on both M1 and Intel builds. Luckily Apple provides a simply way to silence these warnings by setting a single C preprocessor define. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Replaced deprecated constant ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1161/files - new: https://git.openjdk.org/jfx/pull/1161/files/883be169..f3f8fddc Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1161&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1161&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1161.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1161/head:pull/1161 PR: https://git.openjdk.org/jfx/pull/1161 From duke at openjdk.org Wed Jun 28 18:28:02 2023 From: duke at openjdk.org (Martin Fox) Date: Wed, 28 Jun 2023 18:28:02 GMT Subject: RFR: 8310847: [Mac] Silence OpenGL deprecation warnings In-Reply-To: References: <9rhhdkuWDLGtqn3jAaIhtDUt0a9NmGzeZ4eyu1Xd5Hc=.d5260a95-32b2-430b-b9e3-d1c0b6e4417e@github.com> Message-ID: <4fElwz9x0m3wS9bM5vPjriuIpoNXIEvTIbzKE0706lY=.7c7b4bcc-247d-4041-9711-86e2615ec043@github.com> On Wed, 28 Jun 2023 06:37:57 GMT, Ambarish Rapte wrote: >> The Mac build issues a lot of warnings including several related to the deprecation of OpenGL in macOS 10.14. Now that the deployment target for JavaFX is 11.0 across the board these warnings are showing up on both M1 and Intel builds. Luckily Apple provides a simply way to silence these warnings by setting a single C preprocessor define. > > All the OpenGL warnings get silenced except following two: > > 1. modules/javafx.graphics/src/main/native-prism-es2/macosx/MacOSXWindowSystemInterface.m:120:24: warning: 'setView:' is deprecated: first deprecated in macOS 10.14 - Use NSOpenGLView to provide OpenGL content in a Cocoa app. [-Wdeprecated-declarations] > > 2. modules/javafx.graphics/src/main/native-prism-es2/macosx/MacOSXWindowSystemInterface.m:181:57: warning: 'NSOpenGLCPSwapInterval' is deprecated: first deprecated in macOS 10.14 [-Wdeprecated-declarations] > > Could you please take a look why are these not silenced. The other warnings from same file are silenced but not these. > The first warning does not seem like specific to deprecation of OpenGL. But the second one does. > Please take a quick look if can be solved, otherwise looks good. > > I shall approve the PR as-is. and shall re-aproove if any changes. @arapte NSOpenGLCPSwapInterval is deprecated in favor of NSOpenGLContextParameterSwapInterval. I've updated the PR. Apparently Apple deprecated OpenGL and cleaned up the API all at the same time. Prism creates an NSOpenGLContext and then attaches it to the NSView using `setView:`. This approach is deprecated, the recommended way is to create an NSOpenGLView or CAOpenGLLayer and use the associated context. I don't understand Prism at all so can't really address this. (In fact I'm confused. In Glass the 3D view is an NSOpenGLView and also creates a CAOpenGLLayer which seems redundant. Then there's this Prism code that is creating an NSOpenGLContext and attaching it to the NSView? I'm sure it all makes sense but it would nice to see some documentation on how this all hangs together.) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1161#issuecomment-1611885532 From kcr at openjdk.org Thu Jun 29 21:15:11 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 29 Jun 2023 21:15:11 GMT Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value [v7] In-Reply-To: References: Message-ID: On Wed, 29 Mar 2023 17:31:42 GMT, Michael Strau? wrote: >>> > @andy-goryachev-oracle raises a good point about perhaps wanting to solve this in a similar way for the various places where we need to do some sort of iterative adjustment (such as here and in the eventual solution for JDK-8299753). It seems also worth looking at what @Maran23 proposes for AnchorPane to fix JDK-8295078 in PR #910 (for which the review still needs to be completed). >>> >>> Yes, at this point we should probably discuss what would be the best solution to fix the snapping issues once and for all. We might even want to look into other frameworks like Swing. Maybe there are people internally at Oracle who can give valuable input here too? >> >> I think extracting the common code out of HBox and VBox would be good, as they're basically doing the same thing in a different axis. The code could then be unit tested directly (ie. given a set of min/max/pref sizes, a target size and a "snapper", calculate optimal sizes). Something like this: >> >> double[] distribute(double space, double[] minWidths, double[] maxWidths, Snapper snapper); >> >> The minWidths/maxWidths would be min + pref or pref + max depending on the situation, but this function wouldn't care. The `Snapper` here would be aware of the scale, and would be a dummy implementation that does nothing when snapping is disabled. >> >> This purposely does not handle spacing between children, as you can calculate that before hand and adjust `space` to the actual space available for children, simplifying the code. >> >> Disclaimer: I used to create my own layout manager (see: [smartlayout](https://github.com/hjohn/hs.ui.smartlayout/blob/master/src/main/java/hs/smartlayout/LayoutRequirements.java)) that took into account min/max and weight of each child, and even groups of children (a restriction over two or more children at once) -- weight would affect resizing, allowing you to make layouts where children took space according to some ratio (1:2:3 for example). This functionality I called a `SpaceDistributor` which was purposely given a neutral name as it could be used for both horizontal or vertical calculations. When including weight, the calculations could get so complex that I had multiple implementations and an exhaustive search implementation (which was used by unit tests to verify the optimized implementations). This was before scaling became an issue though, so this code did not take snapping values to pixels into account. > > Thank you very much @hjohn for your extensive review. Before addressing your comments, I'd like to get some clarification (ideally also from @kevinrushforth), because I am a bit confused by the discussion so far. > > This PR is a very narrow patch that fixes an obvious bug in `HBox` and `VBox`. It's narrow in that it doesn't change the present algorithm, it merely corrects some of its flaws. There is a little bit of refactoring, but that's only done where it helps readers to better understand the algorithm. > > However, the discussion seems to center around the idea of large-scale refactoring, even across multiple components, including open tickets like [8299753](https://bugs.openjdk.org/browse/JDK-8299753). That's not something I can do as part of this PR, and if large-scale refactoring is the way we choose to go forward, I'd rather not spend more of my time on this particular PR. There needs to be a realistic chance that this PR will be accepted for integration basically as it is. > > If we want to expand the scope of this work, this PR should be closed and the discussion should be continued on the mailing list. PR #1111 is likely to be the eventual solution for the general problem of handling layout when snap-to-pixel is set (as it is by default). So the question I have, primarily for @mstr2 and @hjohn, is: Is this PR a reasonable step along the path to where we want to go? Or will it need to be reworked or reverted if and when we get to PR #1111 ? If it's the former, it might make sense to revive this PR and take it forward. Otherwise, it should probably be closed in favor of continuing work on PR #1111 ------------- PR Comment: https://git.openjdk.org/jfx/pull/445#issuecomment-1613815862 From jhendrikx at openjdk.org Thu Jun 29 21:38:09 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 29 Jun 2023 21:38:09 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v6] In-Reply-To: References: Message-ID: <7egKB_VOEdFKcrJ1l3O50zlJNezAz1U5Np55fTKoWk4=.eb6e650d-16f7-4ac1-aea6-8530e03d4f1b@github.com> > Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Changed subscription methods to use the subscribe name ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1069/files - new: https://git.openjdk.org/jfx/pull/1069/files/f1dd27c4..1f40a4b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=04-05 Stats: 111 lines in 8 files changed: 69 ins; 25 del; 17 mod Patch: https://git.openjdk.org/jfx/pull/1069.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1069/head:pull/1069 PR: https://git.openjdk.org/jfx/pull/1069 From kcr at openjdk.org Thu Jun 29 22:06:07 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 29 Jun 2023 22:06:07 GMT Subject: RFR: 8309935: Mac - SystemMenuBar, IndexOutOfBoundsException on change [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 07:24:51 GMT, Florian Kirmaier wrote: >> Fixing JDK-8309935 and providing a test for it. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > small changes based on code review Looks good. Tested with the provided system test on Mac, where it fails without and passes with the fix. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1152#pullrequestreview-1506193184 From jhendrikx at openjdk.org Thu Jun 29 22:22:01 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 29 Jun 2023 22:22:01 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v2] In-Reply-To: <3N9jbm3k-QZKwMYL6uqzLTauubbyUmv-i13-rcKzcak=.01deb591-7e04-4e0d-86de-e94884ae344b@github.com> References: <1ybACQTFTQ4PqtoPyikEJ0WM0i6p-Sou3BOBKOpCrrA=.fdfe08aa-9458-4e6b-a099-2331a89bf951@github.com> <0hH8-9k1R9vTiRnukBMBjkt3UxspriLXm82KpDp8O9Q=.d96da3b6-6efc-41d4-bd5c-11af61f1256b@github.com> <1C7nRZSxHigJbFU6nLiU951oR3iRp-dzF5t1R1ZGF_Y=.5440cce4-2712-4e4b-944d-6c2128b97676@github.com> <3N9jbm3k-QZKwMYL6uqzLTauubbyUmv-i13-rcKzcak=.01deb591-7e04-4e0d-86de-e94884ae344b@github.com> Message-ID: <_hLJuDFJWOlmnrpoLPT04-H8we7ARs1ppEy3FMUrwRk=.77544d94-0045-4760-861b-5e8aaabefda5@github.com> On Wed, 28 Jun 2023 15:05:24 GMT, John Hendrikx wrote: >>> My suggestion is to have the following new operations: >>> >>> * `subscribe` (`Runnable`, `Consumer`, `BiConsumer`) >> >> This seems reasonable. I could be talked into the longer names, but I prefer the overloaded `subscribe` name. >> >>> * `subscribeListener` (`InvalidationListener`, `ChangeListener`) >> >> This might be a useful follow-on Enhancement, but I wouldn't do it as part of this one. > > I prefer short names here as often there will be a lambda or method reference following it that makes it clear what you're doing, so I guess that's a vote for `subscribe` plus overrides then. I've updated this PR now to use the `subscribe` naming, and created a corresponding CSR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1247224808 From kpk at openjdk.org Fri Jun 30 05:41:05 2023 From: kpk at openjdk.org (Karthik P K) Date: Fri, 30 Jun 2023 05:41:05 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v2] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: On Fri, 23 Jun 2023 15:45:21 GMT, Andy Goryachev wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale) (I think). > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Left a inline comment. Otherwise looks good to me modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 112: > 110: distribute(delta, pref); > 111: } > 112: } else if (delta > 0.0) { Do we need delta = 0.0 condition here? ------------- Marked as reviewed by kpk (Committer). PR Review: https://git.openjdk.org/jfx/pull/1156#pullrequestreview-1506543354 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1247456039 From jhendrikx at openjdk.org Fri Jun 30 09:58:04 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 30 Jun 2023 09:58:04 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v2] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: <07JDRMxcdryYit4bsUbbJrldyiQIGF7WuHQpsvVZNDs=.c988ed00-db00-4b1f-807f-7202b9609227@github.com> On Tue, 27 Jun 2023 18:23:29 GMT, Andy Goryachev wrote: > @hjohn would you mind taking a look at this? using the ideas from your SpaceDistributor Will take a look this weekend ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1614422355 From duke at openjdk.org Fri Jun 30 12:49:06 2023 From: duke at openjdk.org (duke) Date: Fri, 30 Jun 2023 12:49:06 GMT Subject: Withdrawn: JDK-8298104: NPE on synchronizeSceneNodes() In-Reply-To: References: Message-ID: On Wed, 3 May 2023 11:46:50 GMT, Daniel wrote: > A null pointer exception occurs on the ScenePulseListener when iterating through the dirty node list. > A null check is needed on the node before calling node.getScene(). > > The error occurs occasionally and causes the application to crash. > > Issue: [JDK-8298104: NPE on synchronizeSceneNodes()](https://bugs.openjdk.org/browse/JDK-8298104) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1123 From kpk at openjdk.org Fri Jun 30 14:40:14 2023 From: kpk at openjdk.org (Karthik P K) Date: Fri, 30 Jun 2023 14:40:14 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow [v4] In-Reply-To: References: Message-ID: > The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when Text node was embedded in TextFlow. Hence wrong character index value was calculated for the same. > > Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index. > > Added tests to validate the changes. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Fix character index calculation issue ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1157/files - new: https://git.openjdk.org/jfx/pull/1157/files/c7eac8ab..1ea7365c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1157&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1157&range=02-03 Stats: 22 lines in 1 file changed: 16 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1157.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1157/head:pull/1157 PR: https://git.openjdk.org/jfx/pull/1157 From angorya at openjdk.org Fri Jun 30 15:43:06 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 30 Jun 2023 15:43:06 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v2] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: <_ps97OnsqbqQknpoJfD8OnEEwtFWY5YDD6Y6ga318cg=.a261c3d5-f17a-42a4-8b36-191bb2d8a212@github.com> On Fri, 30 Jun 2023 05:38:03 GMT, Karthik P K wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 112: > >> 110: distribute(delta, pref); >> 111: } >> 112: } else if (delta > 0.0) { > > Do we need delta = 0.0 condition here? excellent question. we don't - zero delta means no change, so no action is needed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1248011392 From kpk at openjdk.org Fri Jun 30 15:59:01 2023 From: kpk at openjdk.org (Karthik P K) Date: Fri, 30 Jun 2023 15:59:01 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow [v4] In-Reply-To: References: Message-ID: On Fri, 30 Jun 2023 14:40:14 GMT, Karthik P K wrote: >> The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when Text node was embedded in TextFlow. Hence wrong character index value was calculated for the same. >> >> Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index. >> >> Added tests to validate the changes. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Fix character index calculation issue Fixed the character index and insertion index issue mentioned above. Please check. One more issue I observed is that when Text node is displayed in single line, correct x coordinate is picked up by Mouse event, but when text is displayed in more than one line, x coordinate picked up by Mouse event at the same position is different. image x value in highlighted position is 7.01 ![image](https://github.com/openjdk/jfx/assets/26969459/5e521813-1bd3-4200-b5c1-424597795010) x value in highlighted position is 83.0. Looks like there is issue in MouseEvent or PickResult. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1614858985 From angorya at openjdk.org Fri Jun 30 17:24:59 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 30 Jun 2023 17:24:59 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow [v4] In-Reply-To: References: Message-ID: On Fri, 30 Jun 2023 15:56:45 GMT, Karthik P K wrote: > Looks like there is issue in MouseEvent or PickResult. Do you mean MouseVent.getX()? I cannot reproduce that (in the Monkey Tester). I've added a mouse handler to the control (Text or TextFlow, depending on the page) and ev.getX() always returns correct result. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1614952491 From angorya at openjdk.org Fri Jun 30 17:37:59 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 30 Jun 2023 17:37:59 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow [v4] In-Reply-To: References: Message-ID: On Fri, 30 Jun 2023 14:40:14 GMT, Karthik P K wrote: >> The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when Text node was embedded in TextFlow. Hence wrong character index value was calculated for the same. >> >> Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index. >> >> Added tests to validate the changes. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Fix character index calculation issue Part of the issue seems fixed, but i noticed an irregularity with the tone skin emoji. Now we do not support grapheme clusters (yet), but still, the insertion index reported by Text suddenly jumps from a correct value to what looks like a too big of a value. In the following screenshots, if the mouse pointer is hovering to the left of the red caret line, the insertion index is 4. But if you move it to the right side, the index jumps to 33 which does not look right. Mouse to the left of the line: ![Screenshot 2023-06-30 at 10 14 53](https://github.com/openjdk/jfx/assets/107069028/6339dc66-5305-42e7-a06a-994aa4e3c000) Mouse to the right of the line: ![Screenshot 2023-06-30 at 10 15 00](https://github.com/openjdk/jfx/assets/107069028/bbb29e2d-ed51-462b-9731-9a14acec77eb) I can tell that the red line on the screenshots corresponds to a boundary between two different Text instances (see TextFlowPage:204). The TextFlow portion does seem to work correctly. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1614967666 From jvos at openjdk.org Fri Jun 30 17:49:03 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 30 Jun 2023 17:49:03 GMT Subject: RFR: 8311185: VirtualFlow jump when cellcount changes Message-ID: When the cellcount changes, we need to make sure that the size of the current first visible cell is known. This avoids index errors due to the current offset (between the top of the viewport and the current first visible cell) being potentially larger than the new estimated cellsize. Added a test that fails before and succeeds after the patch. The test uses the same logic as the reproducer in the JBS issue. ------------- Commit messages: - When the cellcount changes, we need to make sure that the size of the current first visible cell is known. Changes: https://git.openjdk.org/jfx/pull/1164/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1164&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311185 Stats: 19 lines in 2 files changed: 19 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1164.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1164/head:pull/1164 PR: https://git.openjdk.org/jfx/pull/1164 From angorya at openjdk.org Fri Jun 30 18:49:58 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 30 Jun 2023 18:49:58 GMT Subject: RFR: 8311185: VirtualFlow jump when cellcount changes In-Reply-To: References: Message-ID: On Fri, 30 Jun 2023 17:43:56 GMT, Johan Vos wrote: > When the cellcount changes, we need to make sure that the size of the current first visible cell is known. > > This avoids index errors due to the current offset (between the top of the viewport and the current first visible cell) being potentially larger than the new estimated cellsize. > > Added a test that fails before and succeeds after the patch. The test uses the same logic as the reproducer in the JBS issue. this is a very obscure scenario! tested with and without the fix with the attached test program. observed no ill effects with a subset of tests in the MonkeyTester. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1164#pullrequestreview-1507728033 From angorya at openjdk.org Fri Jun 30 23:01:02 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 30 Jun 2023 23:01:02 GMT Subject: RFR: JDK-8304439: Subscription based listeners [v6] In-Reply-To: <7egKB_VOEdFKcrJ1l3O50zlJNezAz1U5Np55fTKoWk4=.eb6e650d-16f7-4ac1-aea6-8530e03d4f1b@github.com> References: <7egKB_VOEdFKcrJ1l3O50zlJNezAz1U5Np55fTKoWk4=.eb6e650d-16f7-4ac1-aea6-8530e03d4f1b@github.com> Message-ID: <8g4mZmGv2L296BlRze45BwpoM69y2WNnlSMoDldBaXc=.a8777248-1931-4fd4-bd85-8d87a8bb7546@github.com> On Thu, 29 Jun 2023 21:38:09 GMT, John Hendrikx wrote: >> Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Changed subscription methods to use the subscribe name modules/javafx.base/src/main/java/com/sun/javafx/binding/ConditionalBinding.java line 102: > 100: } > 101: } > 102: } missing newline? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1248328610