From andy.goryachev at oracle.com Fri Dec 1 00:11:50 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 1 Dec 2023 00:11:50 +0000 Subject: CssMetaData.combine() Message-ID: Dear colleagues: there were a couple of comments after I withdrew https://github.com/openjdk/jfx/pull/1296for reasons of frustration, so I wanted to respond to those in the openjfx list. > I pondered that back when I was working on replacing these static initializers with the .of collection variants. It doesn't work here for problem stated above - we need to modify an unmodifiable list, which is why I didn't touch them in that pass. While the proposed method is useful for eliminating some ugly syntax, cementing a questionable API with more a public API doesn't seem to me like the right direction. If the method is made internal only, then that's fine. Alternatively, if the method is made useful outside of this specific context, then even if it won't be used here, it could be used in other places, and that's also fine. Even though the syntax is ugly, the current implementation of the static getClassCssMetaData() is nearly perfect, considering the lack of some kind of a 'lazy' keyword in java. What the current code does is two things - a lazy initialization, meaning the code will get executed only when needed, and it has zero per-instance overhead. I don't think anyone can suggest a better way of doing it. I don't buy Nir's argument about "questionable API". The API is codified by Node.getCssMetaData() and the current implementation will be perfect with the proposed utility method (and maybe we can address some other comments from https://git.openjdk.org/jfx/pull/1293#discussion_r1411406802 ). I do like what Michael suggested - is to provide a (better) explanation for CssMetaData.combine(), including the requirements on the user code that wants to provide CSS styling for the custom controls. I still think this PR has merit, the custom component devs will certainly benefit from it, a few bytes and cpu cycles would get saved. I don't mind reopening the PR, may be extending its scope to use the new utility in all the core controls and skins. And I would be very much interested to hear from Nir his idea of an API that is not questionable. I think we'll all benefit from learning how to make javafx better. -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Fri Dec 1 03:57:40 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 1 Dec 2023 04:57:40 +0100 Subject: CssMetaData.combine() In-Reply-To: References: Message-ID: <154ba5f4-06d7-9832-0bcc-0dc2c5680ddd@gmail.com> Hi Andy, Let me start to say that I had no problem with this PR being merged as I already agreed with one of the first versions. Sometimes then on the same PR there can be some discussions on what else can be done in this area, potentially maybe even alleviating the need for the change (X/Y problem, ie. why do you need this method? Because you need to concatenate lists, but the underlying reason is that the CSS property initialization is somewhat clumsy). On 01/12/2023 01:11, Andy Goryachev wrote: > > Dear colleagues: > > there were a couple of comments after I > withdrewhttps://github.com/openjdk/jfx/pull/1296 > for reasons of frustration, > so I wanted to respond to those in the openjfx list. > > >I pondered that back when I was working on replacing these static > initializers with the|.of|collection variants. It doesn't work here > for problem stated above - we need to modify an unmodifiable list, > which is why I didn't touch them in that pass. While the proposed > method is useful for eliminating some ugly syntax, cementing a > questionable API with more a public API doesn't seem to me like the > right direction. If the method is made internal only, then that's > fine. Alternatively, if the method is made useful outside of this > specific context, then even if it won't be used here, it could be used > in other places, and that's also fine. > > Even though the syntax is ugly, the current implementation of the > static getClassCssMetaData() is/nearly perfect/, considering the lack > of some kind of a 'lazy' keyword in java. > It may be "nearly perfect" from an optimization viewpoint, but it is clumsy and unwieldy for anyone wanting to implement CSS properties. > > What the current code does is two things - a lazy initialization, > meaning the code will get executed only when needed, and it has zero > per-instance overhead. ?I don't think anyone can suggest a better way > of doing it. > This was already mentioned on the PR, but I'll repeat it here: what is the lazy initialization for?? As soon as these Nodes need to be shown, all the metadata will have been queried already. I don't see any benefit making them lazy so you can create Nodes faster, as long as they are never shown. > I don't buy Nir's argument about "questionable API".? The API is > codified by Node.getCssMetaData() and the current implementation will > be perfect with the proposed utility method (and maybe we can address > some other comments > fromhttps://git.openjdk.org/jfx/pull/1293#discussion_r1411406802 > ). > How can there be any doubt that this API is questionable?? It ignores a core feature of Java (inheritance) and moves this burden to the user by calling static methods of its direct parent... in order to implement CSS property **inheritance** -- it also burdens any subclass with the caching of these properties (because "performance"), and to make those properties publicly (and statically) available so another subclass might "inherit" them. The API is clumsy enough that I loathe creating stylable properties for the sheer amount of boilerplate that surrounds them. Some alternatives have been suggested, but are shot down without thinking along to see if there might be something better possible here.? Solutions where some of the common logic is moved to either Node or the CSS subsystem are certainly worth considering. > ... a few bytes and cpu cycles would get saved ... > This is not for you specifically, but JavaFX has a lot of "optimizations", some resulting in really questionable patterns that have/are hurting us: - Reimplementing core collection classes for some benefit, but then only partially implementing them (and often buggy), and/or completely breaking the collection contract [BitSet] - Lazy initialization in many places that IMHO is not needed (benchmark should be time to show window, anything accessed before that need not be lazy, and is likely counterproductive) - Using plain arrays in many places, with a lot of custom code that's already available in some standard collection class or as a standard pattern; the custom code often has untested edge cases that contain bugs [ExpressionHelper] - Making things mutable; surely mutating something must always be faster than having to create a new object? Except that if there's a lot of duplication going on because these objects are unshareable (because mutable), the cost/benefit is no longer so clear (but try to prove that with a micro benchmark) [PseudoClassState / StyleClassSet] - Also see many usages of LinkedList, a class that if you'd never use it, you'd be better off 99.999% of the time; use of that class should always be explained in a comment, and proven to be better with a benchmark [too many places to list] The list goes on; many of the optimizations I've seen would make sense for C/C++, but not for Java.? Now I don't mind some optimizations, but practically none of them are documented (deviating from the standard path always deserves an explanation for the next developer) and I suspect they were never verified either.? I've done extensive "optimization" before, with benchmarks, and you'd be surprised what is actually faster, and what makes no difference whatsoever -- even then, after benchmarking, if the difference is small, it's best to use established patterns, as that's what the JDK optimizes for.? What is marginally faster now, may not be faster on the next JDK, with a different GC, when run in a real application (caches will be used differently), or on a completely different architecture. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Fri Dec 1 04:35:18 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 1 Dec 2023 04:35:18 GMT Subject: RFR: 8320359: ImageView: add styleable fitWidth, fitHeight, preserveRatio, smooth properties [v3] In-Reply-To: References: Message-ID: <0qUCYcUVa23v8VhGc4mhYeDJsBTandW6eBn8og7UJqg=.68762f7c-2618-4c30-9a15-0b76ab258616@github.com> On Thu, 30 Nov 2023 23:24:40 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/CssUtil.java line 75: >> >>> 73: >>> 74: /** immutable list with random access backed by an array */ >>> 75: private static class ImmutableArrayList extends AbstractList implements RandomAccess { >> >> I'd like to point that a skeletal implementation of `AbstractList` will perform worse than `ArrayList` for any method that needs to walk the list, as the `AbstractList` will use iterators for methods like `indexOf`, `hashCode` and `equals`. Now that will probably be irrelevant, but as this seems to be a micro optimization, you should be aware of all the trade offs. > > Good point, thanks! > This also applies to UnmodifiableArrayList. > > For completeness sake, I wanted to mention a few issues (not in scope for this PR) that came out of the code review: > > - could use `UnmodifiableArrayList` but it stores extra int size. perhaps a factory method can be added to it for when `size != elements.length`. > - could improve UnmodifiableArrayList with fast(er) `indexOf`, `hashCode`, `equals` per @hjohn 's comment earlier > - `Control.getCssMetaData()` can be improved to skip merging of two lists if skinBase is null > - the same immutable list should be used in `Control.getCssMetaData()` instead of `ArrayList()` I wouldn't do any of the above unless there is a very good reason (and I'm not seeing one). Just use standard `List.of` as the last step (or use the `Collections.unmodifableList` wrapper); you'll get the most optimized, automatically maintained, bugfree, immutable `List` implementation Java has to offer. It means another copy will be made; that's fine, this only happens once -- it's not in a hot path. If you feel like optimizing something, don't bother with `Control.getCssMetaData` either; instead, deduplicate the property lists so there is only one list per unique `Skin` + `Control` combo. That saves a **complete** list per control **instance**. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1293#discussion_r1411589101 From arapte at openjdk.org Fri Dec 1 10:10:19 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 1 Dec 2023 10:10:19 GMT Subject: RFR: 8092272: [D3D 3D] Need a robust 3D states management for texture [v2] In-Reply-To: References: <6xKLzZARce0g3rRgAeOD-4IqxTsFi0CRl5zRqGjbyeA=.e3cfc498-8cd8-4aee-9301-a3238e5867f7@github.com> Message-ID: On Wed, 15 Nov 2023 11:39:30 GMT, Lukasz Kostyra wrote: >> 1. Not when it will be promoted to public API. Adding record components breaks backwards compatibility, so making this a record will not allow adding more configuration later on. What might be possible is making it an interface and using a record as an implementation. >> 2. I think that this class can go beyond sampler configurations. For example, wrapping is a render state, not a sampler state. Maybe something more general like "TextureParameters" can work. > > I agree with 2. and I also think that `TextureParameters` would be a better name for this. > > This should also follow in below method names and such (ex. `setTextureParameters()` instead of `setTextureData()`) These properties/parameters are actually Sampler properties. But `Sampler` is implementation detail and so is `Texture`. Will it be good idea or overkill to use different naming instead, like for example how we use [ImageSmoothing](https://openjfx.io/javadoc/21/javafx.graphics/javafx/scene/canvas/GraphicsContext.html#setImageSmoothing(boolean)) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1411882540 From arapte at openjdk.org Fri Dec 1 10:10:23 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 1 Dec 2023 10:10:23 GMT Subject: RFR: 8092272: [D3D 3D] Need a robust 3D states management for texture [v2] In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 23:39:21 GMT, Nir Lisker wrote: >> Moves the filter setting of the samplers from the device parameters configuration to the use-site, allowing for dynamic changes in the sampler. This PR does internal plumbing work only to bring it close to the ES2 pipeline. A followup PR will create the public API. >> >> Summary of the changes: >> * Created a new (internal for now) `TextureData` object that is intended to contain all the data of texture (map) of `PhongMaterial`, such as filters, addressing, wrapping mode, mipmaps etc. **This PR deals only with filters** as a starting point, more settings can be added later. >> * Creates an update mechanism from the Java side material to the native D3D layer. The public API `PhoneMaterial` is *not* changed yet. The peer `NGPhongMaterial` is configured to receive update from the public `PhongMaterial` when the public API is created via new `ObjectProperty` properties. >> * Small refactoring in the D3D layer with a new map types enum to control the texture settings more easily. >> >> The JBS issue lists some regressions in a comment, but I couldn't reproduce them. It looks like the sampler settings needed to be added anywhere, and that was the easiest to do at the time. Now they were just moved. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc line 367: > 365: { > 366: static const std::array minMagEnumMap = { D3DTEXF_POINT, D3DTEXF_LINEAR }; > 367: static const std::array mipmapEnumMap = { D3DTEXF_NONE, D3DTEXF_POINT, D3DTEXF_LINEAR }; I think these should be class or file level arrays or enums instead of here. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1411817285 From arapte at openjdk.org Fri Dec 1 11:03:31 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 1 Dec 2023 11:03:31 GMT Subject: [jfx21u] RFR: 8318708: FX: Update copyright year in docs, readme files to 2024 Message-ID: A clean backport to jfx21u, to update copyright year in doc files. ------------- Commit messages: - update cpr-year in docs to 2024 Changes: https://git.openjdk.org/jfx21u/pull/36/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=36&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318708 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx21u/pull/36.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/36/head:pull/36 PR: https://git.openjdk.org/jfx21u/pull/36 From kcr at openjdk.org Fri Dec 1 13:01:13 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Dec 2023 13:01:13 GMT Subject: RFR: 8301302: Platform preferences API [v34] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 30 Nov 2023 01:38:13 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > initialize field with NULL @jperedadnr you might want to review the changes in Application / WinApplication since it changes how high-contrast mode is handled. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1836078467 From kcr at openjdk.org Fri Dec 1 13:28:23 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Dec 2023 13:28:23 GMT Subject: [jfx21u] RFR: 8313648: JavaFX application continues to show a black screen after graphic card driver crash Message-ID: <-U2agtAv37vAzQlTAwyg4uIOmfn8ZVhSzH_GYPG6rDk=.6069a71c-8b9f-4030-a465-3f475f83a463@github.com> Clean backport to jfx21u. This backport was already requested and approved in JBS. ------------- Commit messages: - Backport b80ec391cbba72d84b4b862b3f1b8db2ff8eb6e2 Changes: https://git.openjdk.org/jfx21u/pull/37/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=37&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313648 Stats: 24 lines in 2 files changed: 14 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jfx21u/pull/37.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/37/head:pull/37 PR: https://git.openjdk.org/jfx21u/pull/37 From kcr at openjdk.org Fri Dec 1 13:48:28 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Dec 2023 13:48:28 GMT Subject: [jfx21u] Integrated: 8313648: JavaFX application continues to show a black screen after graphic card driver crash In-Reply-To: <-U2agtAv37vAzQlTAwyg4uIOmfn8ZVhSzH_GYPG6rDk=.6069a71c-8b9f-4030-a465-3f475f83a463@github.com> References: <-U2agtAv37vAzQlTAwyg4uIOmfn8ZVhSzH_GYPG6rDk=.6069a71c-8b9f-4030-a465-3f475f83a463@github.com> Message-ID: On Fri, 1 Dec 2023 13:24:17 GMT, Kevin Rushforth wrote: > Clean backport to jfx21u. This backport was already requested and approved in JBS. This pull request has now been integrated. Changeset: 18fef3f2 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx21u/commit/18fef3f28ddc3000794a4d4848865ee8c12152c7 Stats: 24 lines in 2 files changed: 14 ins; 4 del; 6 mod 8313648: JavaFX application continues to show a black screen after graphic card driver crash Backport-of: b80ec391cbba72d84b4b862b3f1b8db2ff8eb6e2 ------------- PR: https://git.openjdk.org/jfx21u/pull/37 From kcr at openjdk.org Fri Dec 1 13:59:19 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Dec 2023 13:59:19 GMT Subject: RFR: 8318388: Update libxslt to 1.1.39 [v2] In-Reply-To: <__VrzBWVNNYqsH9q-qh8aqW8Qob1j0drUiStyDsfufs=.f517d9a7-0fed-4de2-b56b-3a72b4f4d818@github.com> References: <__VrzBWVNNYqsH9q-qh8aqW8Qob1j0drUiStyDsfufs=.f517d9a7-0fed-4de2-b56b-3a72b4f4d818@github.com> Message-ID: On Thu, 30 Nov 2023 08:37:35 GMT, Hima Bindu Meda wrote: >> Updated libxslt to v1.1.39. Verified build on all platforms.No issue seen. > > Hima Bindu Meda has updated the pull request incrementally with two additional commits since the last revision: > > - update license for libxslt > - update libxslt.md Reviewers: @kevinrushforth @johanvos @tiainen ------------- PR Comment: https://git.openjdk.org/jfx/pull/1298#issuecomment-1836160217 From kpk at openjdk.org Fri Dec 1 14:28:43 2023 From: kpk at openjdk.org (Karthik P K) Date: Fri, 1 Dec 2023 14:28:43 GMT Subject: RFR: 8282290: TextField Cursor Position one off [v3] In-Reply-To: References: Message-ID: <3O0CgH2CRPXmxTsFHviBRSFqbKn2s6H_7LLSKHtExSw=.1534fb3e-1648-4d83-930f-e3010c5bed62@github.com> > The change listener on caretPositionProperty() was not getting invoked on replacing the content with same text as there was no change in caret position. Since the textProperty invalidation sets the forward bias to true by default, incorrect caret position was calculated when the same text was replaced after clicking on the trailing edge of last character or empty space in the TextField. > > Since caretShapeProperty invalidation listener gets invoked without changing the caret position, updating the caretBiasProperty on this listener solves the issue. > > Since the caret position value will be same when the caret is present after the last character or before the last character, it can not be validated using unit test. > The fix can be validated using MonkeyTester. > Steps to select TextField option in Monkey Tester. > > - Open the MonkeyTester app and select TextField from the left option pane. > - Select Short from Text selection option and click on the TextField to bring it into focus. > - Select all using cmd(ctrl) + a and copy using cmd(ctrl) + c > - Click on empty space in the TextField after the present content. > - Select all again using the keyboard shortcut and paste using cmd(ctrl) + v > - The caret should be displayed after the last character. Without the fix caret gets displayed before the last character. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1287/files - new: https://git.openjdk.org/jfx/pull/1287/files/79f2fe82..15567b2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1287&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1287&range=01-02 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1287.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1287/head:pull/1287 PR: https://git.openjdk.org/jfx/pull/1287 From kpk at openjdk.org Fri Dec 1 14:28:45 2023 From: kpk at openjdk.org (Karthik P K) Date: Fri, 1 Dec 2023 14:28:45 GMT Subject: RFR: 8282290: TextField Cursor Position one off [v2] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 07:44:13 GMT, Karthik P K wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Code review > > @andy-goryachev-oracle and @Maran23 please re-review when you get a chance. > @karthikpandelu I think this change also fixes [JDK-8248914](https://bugs.openjdk.org/browse/JDK-8248914) - could you please double check? If so, we can add that ticket to this PR. > Yes it fixes [JDK-8248914](https://bugs.openjdk.org/browse/JDK-8248914). I'll add this bug to this PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1287#issuecomment-1836201608 From kpk at openjdk.org Fri Dec 1 14:28:46 2023 From: kpk at openjdk.org (Karthik P K) Date: Fri, 1 Dec 2023 14:28:46 GMT Subject: RFR: 8282290: TextField Cursor Position one off [v2] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 17:47:40 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Code review > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java line 248: > >> 246: textNode.caretShapeProperty().addListener(observable -> { >> 247: caretPath.getElements().setAll(textNode.caretShapeProperty().get()); >> 248: if (caretPath.getElements().size() != 4) { > > could you add a comment explaining why != 4 is here for the future reference. Added comment ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1287#discussion_r1412164025 From angorya at openjdk.org Fri Dec 1 15:26:21 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 1 Dec 2023 15:26:21 GMT Subject: RFR: 8282290: TextField Cursor Position one off [v3] In-Reply-To: <3O0CgH2CRPXmxTsFHviBRSFqbKn2s6H_7LLSKHtExSw=.1534fb3e-1648-4d83-930f-e3010c5bed62@github.com> References: <3O0CgH2CRPXmxTsFHviBRSFqbKn2s6H_7LLSKHtExSw=.1534fb3e-1648-4d83-930f-e3010c5bed62@github.com> Message-ID: On Fri, 1 Dec 2023 14:28:43 GMT, Karthik P K wrote: >> The change listener on caretPositionProperty() was not getting invoked on replacing the content with same text as there was no change in caret position. Since the textProperty invalidation sets the forward bias to true by default, incorrect caret position was calculated when the same text was replaced after clicking on the trailing edge of last character or empty space in the TextField. >> >> Since caretShapeProperty invalidation listener gets invoked without changing the caret position, updating the caretBiasProperty on this listener solves the issue. >> >> Since the caret position value will be same when the caret is present after the last character or before the last character, it can not be validated using unit test. >> The fix can be validated using MonkeyTester. >> Steps to select TextField option in Monkey Tester. >> >> - Open the MonkeyTester app and select TextField from the left option pane. >> - Select Short from Text selection option and click on the TextField to bring it into focus. >> - Select all using cmd(ctrl) + a and copy using cmd(ctrl) + c >> - Click on empty space in the TextField after the present content. >> - Select all again using the keyboard shortcut and paste using cmd(ctrl) + v >> - The caret should be displayed after the last character. Without the fix caret gets displayed before the last character. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Review comments looks good, thanks! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1287#pullrequestreview-1760032235 From angorya at openjdk.org Fri Dec 1 15:35:21 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 1 Dec 2023 15:35:21 GMT Subject: RFR: 8320359: ImageView: add styleable fitWidth, fitHeight, preserveRatio, smooth properties [v3] In-Reply-To: <0qUCYcUVa23v8VhGc4mhYeDJsBTandW6eBn8og7UJqg=.68762f7c-2618-4c30-9a15-0b76ab258616@github.com> References: <0qUCYcUVa23v8VhGc4mhYeDJsBTandW6eBn8og7UJqg=.68762f7c-2618-4c30-9a15-0b76ab258616@github.com> Message-ID: <7Zo9YsuKDs-FLnC3efU6mBThgLptcHhDu4ifZO1RBd4=.d5267675-dc95-4f9c-8aad-90760aaba143@github.com> On Fri, 1 Dec 2023 04:32:16 GMT, John Hendrikx wrote: >> Good point, thanks! >> This also applies to UnmodifiableArrayList. >> >> For completeness sake, I wanted to mention a few issues (not in scope for this PR) that came out of the code review: >> >> - could use `UnmodifiableArrayList` but it stores extra int size. perhaps a factory method can be added to it for when `size != elements.length`. >> - could improve UnmodifiableArrayList with fast(er) `indexOf`, `hashCode`, `equals` per @hjohn 's comment earlier >> - `Control.getCssMetaData()` can be improved to skip merging of two lists if skinBase is null >> - the same immutable list should be used in `Control.getCssMetaData()` instead of `ArrayList()` > > I wouldn't do any of the above unless there is a very good reason (and I'm not seeing one). Just use standard `List.of` as the last step (or use the `Collections.unmodifableList` wrapper); you'll get the most optimized, automatically maintained, bugfree, immutable `List` implementation Java has to offer. It means another copy will be made; that's fine, this only happens once -- it's not in a hot path. > > If you feel like optimizing something, don't bother with `Control.getCssMetaData` either; instead, deduplicate the property lists so there is only one list per unique `Skin` + `Control` combo. That saves a **complete** list per control **instance**. Good point, though I would still not use List.of() because of the unnecessary copy. I agree on `Skin` + `Control` copy. Just not sure how... a static hash table perhaps? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1293#discussion_r1412253329 From kcr at openjdk.org Fri Dec 1 16:23:26 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Dec 2023 16:23:26 GMT Subject: RFR: 8314597: Deprecate for removal protected access methods in converters In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 21:11:43 GMT, Nir Lisker wrote: > Deprecating for removal `getDateFormat()` in `TimeStringConverter` and `DateStringConverter` after it was removed already in `DateTimeStringConverter`, and `getNumberFormat()` in `NumberStringConverter` (and subclasses). Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1294#pullrequestreview-1760163279 From nlisker at openjdk.org Fri Dec 1 16:57:27 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 1 Dec 2023 16:57:27 GMT Subject: RFR: 8092272: [D3D 3D] Need a robust 3D states management for texture [v2] In-Reply-To: References: Message-ID: On Fri, 1 Dec 2023 09:14:28 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed review comments > > modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc line 367: > >> 365: { >> 366: static const std::array minMagEnumMap = { D3DTEXF_POINT, D3DTEXF_LINEAR }; >> 367: static const std::array mipmapEnumMap = { D3DTEXF_NONE, D3DTEXF_POINT, D3DTEXF_LINEAR }; > > I think these should be class or file level arrays or enums instead of here. They are used only in this method. Why would like them to be moved out? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1412360151 From nlisker at openjdk.org Fri Dec 1 17:06:20 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 1 Dec 2023 17:06:20 GMT Subject: RFR: 8092272: [D3D 3D] Need a robust 3D states management for texture [v2] In-Reply-To: References: <6xKLzZARce0g3rRgAeOD-4IqxTsFi0CRl5zRqGjbyeA=.e3cfc498-8cd8-4aee-9301-a3238e5867f7@github.com> Message-ID: On Fri, 1 Dec 2023 10:07:37 GMT, Ambarish Rapte wrote: >> I agree with 2. and I also think that `TextureParameters` would be a better name for this. >> >> This should also follow in below method names and such (ex. `setTextureParameters()` instead of `setTextureData()`) > > These properties/parameters are actually Sampler properties. But `Sampler` is implementation detail and so is `Texture`. Will it be good idea or overkill to use different naming instead, like for example how we use [ImageSmoothing](https://openjfx.io/javadoc/21/javafx.graphics/javafx/scene/canvas/GraphicsContext.html#setImageSmoothing(boolean)) `ImageSmoothing` is very specific. This class can include many configuration options, not only from the sampler, but also from the rendered. I'm not sure what you're suggesting. Maybe I should try to list more of the future options for this class. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1412368579 From kcr at openjdk.org Fri Dec 1 17:42:22 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Dec 2023 17:42:22 GMT Subject: RFR: 8320359: ImageView: add styleable fitWidth, fitHeight, preserveRatio, smooth properties [v3] In-Reply-To: References: Message-ID: <3o0Rk0mLdVuqVQWSoLDfdw8AIQjY4j-XsLzZO6GYQ7A=.a344867a-b16c-4a23-9cd1-55aa9c720c2e@github.com> On Thu, 30 Nov 2023 19:03:38 GMT, Andy Goryachev wrote: >> Adding missing styleable properties to ImageView: >> >> >> -fx-preserve-ratio >> -fx-smooth >> -fx-fit-width >> -fx-fit-height >> >> >> Updated CSS Reference. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > save 8 bytes Looks good. I left one HTML formatting comment on the newly added `cssref.html` docs (I also left an editorial comment that you should feel free to ignore). I'll reapprove if and when you make the suggested doc formatting change. modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 1887: > 1885: -fx-fit-height > 1886: <number> > 1887: 0 Since you don't specify a style class for the newly added properties, they will all be left justified. The existing `null` value for `-fx-image` specifies `class="default"` which centers it. I recommend either adding the `class="default"` to all of the newly added properties, or removing it from the default value of the existing `fx-image` property. I'll reapprove if you want to make the change. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1293#pullrequestreview-1760217314 PR Review Comment: https://git.openjdk.org/jfx/pull/1293#discussion_r1412399522 From kcr at openjdk.org Fri Dec 1 17:42:23 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Dec 2023 17:42:23 GMT Subject: RFR: 8320359: ImageView: add styleable fitWidth, fitHeight, preserveRatio, smooth properties [v3] In-Reply-To: <7Zo9YsuKDs-FLnC3efU6mBThgLptcHhDu4ifZO1RBd4=.d5267675-dc95-4f9c-8aad-90760aaba143@github.com> References: <0qUCYcUVa23v8VhGc4mhYeDJsBTandW6eBn8og7UJqg=.68762f7c-2618-4c30-9a15-0b76ab258616@github.com> <7Zo9YsuKDs-FLnC3efU6mBThgLptcHhDu4ifZO1RBd4=.d5267675-dc95-4f9c-8aad-90760aaba143@github.com> Message-ID: On Fri, 1 Dec 2023 15:32:32 GMT, Andy Goryachev wrote: >> I wouldn't do any of the above unless there is a very good reason (and I'm not seeing one). Just use standard `List.of` as the last step (or use the `Collections.unmodifableList` wrapper); you'll get the most optimized, automatically maintained, bugfree, immutable `List` implementation Java has to offer. It means another copy will be made; that's fine, this only happens once -- it's not in a hot path. >> >> If you feel like optimizing something, don't bother with `Control.getCssMetaData` either; instead, deduplicate the property lists so there is only one list per unique `Skin` + `Control` combo. That saves a **complete** list per control **instance**. > > Good point, though I would still not use List.of() because of the unnecessary copy. > I agree on `Skin` + `Control` copy. Just not sure how... a static hash table perhaps? I will approve this as is, but I agree with John that it would be better to use one of the existing implementations of List: `new UnmodifiableArrayList`, `List.of`, or `Collections.unmodifiableList`. The cost of the extra copy for `List.of` is in the noise compared to the benefit of not having to maintain yet another special case List class. Similarly, the extra word of data storage in `UnmodifiableArrayList` is in the noise. This is a one-per-class not one-per instance list. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1293#discussion_r1412400728 From angorya at openjdk.org Fri Dec 1 18:42:36 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 1 Dec 2023 18:42:36 GMT Subject: RFR: 8320359: ImageView: add styleable fitWidth, fitHeight, preserveRatio, smooth properties [v3] In-Reply-To: <3o0Rk0mLdVuqVQWSoLDfdw8AIQjY4j-XsLzZO6GYQ7A=.a344867a-b16c-4a23-9cd1-55aa9c720c2e@github.com> References: <3o0Rk0mLdVuqVQWSoLDfdw8AIQjY4j-XsLzZO6GYQ7A=.a344867a-b16c-4a23-9cd1-55aa9c720c2e@github.com> Message-ID: On Fri, 1 Dec 2023 17:34:05 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> save 8 bytes > > modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 1887: > >> 1885: -fx-fit-height >> 1886: <number> >> 1887: 0 > > Since you don't specify a style class for the newly added properties, they will all be left justified. The existing `null` value for `-fx-image` specifies `class="default"` which centers it. I recommend either adding the `class="default"` to all of the newly added properties, or removing it from the default value of the existing `fx-image` property. > > I'll reapprove if you want to make the change. thank you! I am going to add class="default" as it allows for styling of the default column. Two notes: - There are a few other places where `class="default"` is omitted (HBox for instance). We may want to fix it in a separate PR. - I don't think the center alignment is the right choice here, I would rather see this column left aligned. Perhaps we should fix the `.default` class as part of the enhancement. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1293#discussion_r1412455129 From angorya at openjdk.org Fri Dec 1 18:42:32 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 1 Dec 2023 18:42:32 GMT Subject: RFR: 8320359: ImageView: add styleable fitWidth, fitHeight, preserveRatio, smooth properties [v4] In-Reply-To: References: Message-ID: > Adding missing styleable properties to ImageView: > > > -fx-preserve-ratio > -fx-smooth > -fx-fit-width > -fx-fit-height > > > Updated CSS Reference. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: class = default ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1293/files - new: https://git.openjdk.org/jfx/pull/1293/files/f735b8bb..f720ddbf Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1293&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1293&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1293.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1293/head:pull/1293 PR: https://git.openjdk.org/jfx/pull/1293 From angorya at openjdk.org Fri Dec 1 19:03:23 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 1 Dec 2023 19:03:23 GMT Subject: RFR: 8320359: ImageView: add styleable fitWidth, fitHeight, preserveRatio, smooth properties [v5] In-Reply-To: References: Message-ID: > Adding missing styleable properties to ImageView: > > > -fx-preserve-ratio > -fx-smooth > -fx-fit-width > -fx-fit-height > > > Updated CSS Reference. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: list of ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1293/files - new: https://git.openjdk.org/jfx/pull/1293/files/f720ddbf..69761b4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1293&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1293&range=03-04 Stats: 22 lines in 1 file changed: 0 ins; 21 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1293.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1293/head:pull/1293 PR: https://git.openjdk.org/jfx/pull/1293 From kcr at openjdk.org Fri Dec 1 19:15:45 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Dec 2023 19:15:45 GMT Subject: RFR: 8320359: ImageView: add styleable fitWidth, fitHeight, preserveRatio, smooth properties [v5] In-Reply-To: References: Message-ID: On Fri, 1 Dec 2023 19:03:23 GMT, Andy Goryachev wrote: >> Adding missing styleable properties to ImageView: >> >> >> -fx-preserve-ratio >> -fx-smooth >> -fx-fit-width >> -fx-fit-height >> >> >> Updated CSS Reference. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > list of Looks good. Once you update the CSR to match the HTML changes, I'll Review that and you can Finalize it. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1293#pullrequestreview-1760420392 From angorya at openjdk.org Fri Dec 1 19:15:46 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 1 Dec 2023 19:15:46 GMT Subject: RFR: 8320359: ImageView: add styleable fitWidth, fitHeight, preserveRatio, smooth properties [v5] In-Reply-To: References: Message-ID: On Fri, 1 Dec 2023 19:12:15 GMT, Kevin Rushforth wrote: > Once you update the CSR updated already ------------- PR Comment: https://git.openjdk.org/jfx/pull/1293#issuecomment-1836639634 From john.hendrikx at gmail.com Fri Dec 1 19:56:13 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 1 Dec 2023 20:56:13 +0100 Subject: Behavior API proof of concept PR In-Reply-To: <2c5318b7-178e-b834-aa6a-2d63f56699da@gmail.com> References: <99ca55ba-72a7-809f-2340-9f3fffe60d53@gmail.com> <2c5318b7-178e-b834-aa6a-2d63f56699da@gmail.com> Message-ID: I've updated the proof of concept PR, and it has a number of changes to allow more reuse of the behaviors handlers and key bindings.? This has resulted in the Behavior installation process to become a bit more complex, but the actual use and the API's are still relatively simple.? For example, SpinnerBehavior's configuration method now looks like this: @Override publicStateFactory> configure(BehaviorInstaller> installer) { installer.setKeyHandler(KEY_HANDLER); installer.registerEventHandler(MouseEvent.MOUSE_PRESSED, State::mousePressed); installer.registerEventHandler(MouseEvent.MOUSE_RELEASED, State::mouseReleased); installer.registerEventHandler(AccessibleActionEvent.TRIGGERED, State::accessibleActionTriggered); installer.registerPropertyListener(Node::sceneProperty, State::sceneChanged); returnState::new; } Changes: - Renamed BehaviorContext to BehaviorInstaller to better reflect its purpose - Behaviors now configure the BehaviorInstaller, and provide a factory for their State ?? - This simplifies all the internal methods of Behaviors, no need for a Control parameter everywhere anymore; State has a Control reference! ?? - Because state and control are now provided at the same time, the handlers can all be static and reusable - Controls create a BehaviorInstaller, ask a Behavior to configure it, then ask the installer to install the handlers on the control, resulting in a Subscription to undo all changes later ?? - This process, although a bit complex, ensures that Behaviors are strictly limited in what changes they can apply to the control ?? - The process also externalizes the Behavior's state, allowing its handlers, listeners and key bindings to be reused accross controls - Introduce a KeyHandler class, and a non-public helper SimpleKeyBinder; these can be a precursor for an InputMap system ?? - KeyHandler is fully static (or can be) to allow key binding reuse ?? - Control can later be made responsible for handling InputMap style overrides Note: earlier it was said that behaviors can be stateless, and this is certainly true for the main Behavior type (which can be "set" on as many controls as you'd like).? However, even Behaviors without "state" still need the Control reference as a piece of state in order to do anything at all.? So, no installed behaviors are actually stateless, there is always at a minimum a control reference.? To better reflect this, the State classes for the two proof of concept behaviors now are constructed with a Control (to keep all the related state together), allowing for easy access to the control for all its methods. The PR is here: https://github.com/openjdk/jfx/pull/1265 --John On 30/11/2023 23:28, John Hendrikx wrote: > > Thanks for having a look! > > On 30/11/2023 19:47, Andy Goryachev wrote: >> >> I think BehaviorContext looks suspiciously like a (skin) input map, >> so I would rather see that. >> >> Invention of State class is a way to work around the stateless >> behavior which, though it adds (in my opinion) very little, might >> still be a feature that app developers want to exploit - at least in >> terms of saving on per-instance key maps.? So any alternative >> proposal should also support a stateless behavior. >> > I'm unsure what you are trying to say here. > > The State class is internal, and can be anything, and take any form.? > If you only need to add a single EventHandler, you can also make that > a class instead of a Lambda and have the state there. The State class, > which can be named anything, is just a convenient way to share state > amongst multiple handlers without having to construct each of them > with special parameters, or having to put the state in the main > class's fields (which would make it not reusable). > > I do however see that I did not take reusability of the keymaps into > account in this version, that will need to be adjusted -- I was more > focused on keeping Behaviors isolated for now, not needing a Control > until installed, and having 0 references between Skins and Behaviors. > > I was hoping for more comments on how the seperation between Skin and > Behavior is done in this PR.? I will attempt to adjust > TextInputControl soon (and I will try a few subclasses of > ButtonBehavior, to see how they can be built "on top" of another > behavior) -- so far I've not found any real problems with this approach. > > --John > >> *From: *openjfx-dev on behalf of John >> Hendrikx >> *Date: *Wednesday, November 29, 2023 at 14:54 >> *To: *openjfx-dev at openjdk.org >> *Subject: *Behavior API proof of concept PR >> >> For those still interested, I've updated >> https://github.com/openjdk/jfx/pull/1265 with a replaced ButtonBehavior >> and SpinnerBehavior, using concepts laid out in >> https://gist.github.com/hjohn/c7b1bf9d4a4770b1b3ae854b20fbaa94 >> >> Any feedback is welcome, I think it's making progress, and the changes >> required seem quite doable. >> >> The ability for Behaviors to intercept any event from its Control or its >> (named) children makes Behaviors a lot more powerful than earlier >> proposals, allowing for completely new interactions without requiring >> Skin changes. >> >> --John >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpereda at openjdk.org Fri Dec 1 20:48:18 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Fri, 1 Dec 2023 20:48:18 GMT Subject: [jfx17u] RFR: 8320267: WebView crashes on macOS 11 with WebKit 616.1 Message-ID: Clean backport of 8320267: WebView crashes on macOS 11 with WebKit 616.1 Reviewed-by: jbhaskar, jpereda ------------- Commit messages: - 8320267: WebView crashes on macOS 11 with WebKit 616.1 Changes: https://git.openjdk.org/jfx17u/pull/168/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=168&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320267 Stats: 191 lines in 2 files changed: 15 ins; 171 del; 5 mod Patch: https://git.openjdk.org/jfx17u/pull/168.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/168/head:pull/168 PR: https://git.openjdk.org/jfx17u/pull/168 From mstrauss at openjdk.org Fri Dec 1 22:14:41 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 1 Dec 2023 22:14:41 GMT Subject: RFR: 8301302: Platform preferences API [v35] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: check for pending exceptions in macOS PlatformSupport ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/9cc3b4bb..dbf24bfe Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=34 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=33-34 Stats: 70 lines in 2 files changed: 34 ins; 14 del; 22 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Fri Dec 1 22:37:50 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 1 Dec 2023 22:37:50 GMT Subject: RFR: 8320359: ImageView: add styleable fitWidth, fitHeight, preserveRatio, smooth properties [v5] In-Reply-To: References: Message-ID: On Fri, 1 Dec 2023 19:03:23 GMT, Andy Goryachev wrote: >> Adding missing styleable properties to ImageView: >> >> >> -fx-preserve-ratio >> -fx-smooth >> -fx-fit-width >> -fx-fit-height >> >> >> Updated CSS Reference. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > list of Marked as reviewed by mstrauss (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1293#pullrequestreview-1760657276 From mstrauss at openjdk.org Sat Dec 2 00:24:36 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 2 Dec 2023 00:24:36 GMT Subject: RFR: 8301302: Platform preferences API [v36] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: check for pending exceptions in GTK PlatformSupport ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/dbf24bfe..0572a363 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=35 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=34-35 Stats: 31 lines in 1 file changed: 19 ins; 7 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From kcr at openjdk.org Sat Dec 2 00:25:50 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 2 Dec 2023 00:25:50 GMT Subject: RFR: 8284544: [Win] Name-Property of Spinner cannot be changed [v3] In-Reply-To: <3oqCt0wtfoCmhSJBJ06FrL8jMdW1BZr0vB3hD3YTxG8=.80674ba3-cc82-4773-87ef-fc981c3889b4@github.com> References: <3oqCt0wtfoCmhSJBJ06FrL8jMdW1BZr0vB3hD3YTxG8=.80674ba3-cc82-4773-87ef-fc981c3889b4@github.com> Message-ID: On Wed, 22 Nov 2023 17:05:36 GMT, Ambarish Rapte wrote: >> Currently we use the value of spinner as it's `UIA_NamePropertyId` when a11y client application requests for it. >> Ideally we should use the text set by `Node.setAccessibleText()` as the `UIA_NamePropertyId`. >> For other controls such as Slider, ListView we use the text set by setAccessibleText() API. >> >> Fix: >> Use the text set by `Node.setAccessibleText()` as the `UIA_NamePropertyId`. >> This means, when a11y client requests `UIA_NamePropertyId`, which is mapped to AccessibleAttribute.TEXT attribute, we shall return the accessible text. >> So we need another way to read out the VALUE of the Spinner. >> - For this we need to implement `IValueProvider` pattern for Spinner control >> - IValueProvider requests the value of the control using it's API `get_ValueString()` >> - It required to introduce a new AccessibleAttribute `VALUE_STRING` >> - IValueProvider also reads out if the control is editable or not, hence added `EDITABLE `case in `Spinner.queryAccessibleAttribute()` >> >> Verification: >> - Run any spinner app, with setAccessibleText set on spinner >> - Run Windows narrator and observe >> - Without this fix: >> - 1. Narrator does not read the text set by setAccessibleText >> - 2. In application "Accessibility Insights for Windows", you can see the value of Spinner as the Name property >> - After this fix: >> - 1. Narrator reads the accessible text then value of Spinner and then if editable or not >> - 2. In application "Accessibility Insights for Windows", you can see the text set by `setAccessibleText()` for Spinner as the Name property and the Spinner's value as value property > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Mac a11y change for VALUE_STRING attribute for Spinner The changes look good and everything works as I would expect. I left one question, but it is fine as you have it. modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java line 805: > 803: break; > 804: case VALUE_STRING: > 805: if (getAttribute(ROLE) == AccessibleRole.SPINNER) { Why qualify this by the AccessibleRole? Might there be other controls in the future that report `VALUE_STRING`? ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1291#pullrequestreview-1760705697 PR Review Comment: https://git.openjdk.org/jfx/pull/1291#discussion_r1412663310 From jpereda at openjdk.org Sat Dec 2 00:33:49 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Sat, 2 Dec 2023 00:33:49 GMT Subject: [jfx17u] Integrated: 8320267: WebView crashes on macOS 11 with WebKit 616.1 In-Reply-To: References: Message-ID: <1RH7xmIBW1EtYeDA_BoESn_fH3dA_kWay_BofKUogZ8=.3470cb09-8670-4f36-a17c-33b5b6bc346e@github.com> On Fri, 1 Dec 2023 20:42:41 GMT, Jose Pereda wrote: > Clean backport of 8320267: WebView crashes on macOS 11 with WebKit 616.1 > Reviewed-by: jbhaskar, jpereda This pull request has now been integrated. Changeset: a9a3f5c5 Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/a9a3f5c5305daa777723431b3bef2162784faf80 Stats: 191 lines in 2 files changed: 15 ins; 171 del; 5 mod 8320267: WebView crashes on macOS 11 with WebKit 616.1 Backport-of: 0d3341704c1ced4f61b5f7f7618e23ec182ae379 ------------- PR: https://git.openjdk.org/jfx17u/pull/168 From mstrauss at openjdk.org Sat Dec 2 01:01:19 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 2 Dec 2023 01:01:19 GMT Subject: RFR: 8301302: Platform preferences API [v34] In-Reply-To: <8o9x6e7VeMb2TaHyVlClUwpu6Bnn3W9OFPAz1KMPy7Q=.247637f1-473d-40ef-8cad-f1d555b5c782@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <8o9x6e7VeMb2TaHyVlClUwpu6Bnn3W9OFPAz1KMPy7Q=.247637f1-473d-40ef-8cad-f1d555b5c782@github.com> Message-ID: On Thu, 30 Nov 2023 22:54:02 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> initialize field with NULL > > modules/javafx.graphics/src/main/native-glass/gtk/PlatformSupport.cpp line 68: > >> 66: jobject PlatformSupport::collectPreferences() const { >> 67: jobject prefs = env->NewObject(jHashMapCls, jHashMapInit); >> 68: if (EXCEPTION_OCCURED(env)) return NULL; > > You should also check for `prefs == NULL` (or `!prefs` as you prefer); Is that necessary? The JNI documentation for `NewObject` states: "Returns a Java object, or NULL if the object cannot be constructed." Is there a non-exceptional way to _not_ construct an instance of a class? > modules/javafx.graphics/src/main/native-glass/gtk/PlatformSupport.cpp line 70: > >> 68: if (EXCEPTION_OCCURED(env)) return NULL; >> 69: >> 70: GtkStyle* style = gtk_style_new(); > > Can `gtk_style_new` return NULL? It's not specified to do so. Internally, it will call `g_object_new`, which is also not specified to return null. I've found some evidence on some gnome.org blog that it will not ever return null, but I haven't looked further than that. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1412689129 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1412688694 From mstrauss at openjdk.org Sat Dec 2 01:04:19 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 2 Dec 2023 01:04:19 GMT Subject: RFR: 8301302: Platform preferences API [v36] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Sat, 2 Dec 2023 00:24:36 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > check for pending exceptions in GTK PlatformSupport I've added a new macro `GLASS_CHECK_EXCEPTIONALLY_RETURN` in the macOS toolkit, which helps to remove some boilerplate when checking every JNI method call. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1836969979 From mstrauss at openjdk.org Sat Dec 2 01:07:22 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 2 Dec 2023 01:07:22 GMT Subject: RFR: 8301302: Platform preferences API [v34] In-Reply-To: <8o9x6e7VeMb2TaHyVlClUwpu6Bnn3W9OFPAz1KMPy7Q=.247637f1-473d-40ef-8cad-f1d555b5c782@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <8o9x6e7VeMb2TaHyVlClUwpu6Bnn3W9OFPAz1KMPy7Q=.247637f1-473d-40ef-8cad-f1d555b5c782@github.com> Message-ID: On Thu, 30 Nov 2023 23:36:38 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> initialize field with NULL > > modules/javafx.graphics/src/main/native-glass/win/GlassApplication.cpp line 174: > >> 172: lParam != NULL && wcscmp(LPCWSTR(lParam), L"ImmersiveColorSet") == 0) && >> 173: m_platformSupport.updatePreferences(m_grefThis)) { >> 174: return 0; > > Do we need to fall through in this case? We used to do so, which is why I'm asking. I decided not to fall through because the documentation for [WM_SETTINGCHANGE](https://learn.microsoft.com/en-us/windows/win32/winmsg/wm-settingchange) says that applications should return zero if they process the message. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1412690588 From mstrauss at openjdk.org Sat Dec 2 01:11:20 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 2 Dec 2023 01:11:20 GMT Subject: RFR: 8301302: Platform preferences API [v34] In-Reply-To: <8o9x6e7VeMb2TaHyVlClUwpu6Bnn3W9OFPAz1KMPy7Q=.247637f1-473d-40ef-8cad-f1d555b5c782@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <8o9x6e7VeMb2TaHyVlClUwpu6Bnn3W9OFPAz1KMPy7Q=.247637f1-473d-40ef-8cad-f1d555b5c782@github.com> Message-ID: <3hZlQbMlmNuttihlul6zw2YRZt9TZ28qDrcwCl7Obzo=.6705eb95-f94c-4305-8ac8-09c96752fdc2@github.com> On Thu, 30 Nov 2023 23:38:18 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> initialize field with NULL > > modules/javafx.graphics/src/main/native-glass/win/GlassApplication.cpp line 189: > >> 187: return 0; >> 188: } >> 189: break; > > In the case of `WM_THEMECHANGED` we used to always return and not exit the switch statement. Could this cause any problems? Like with `WM_SETTINGCHANGE`, the documentation for [WM_THEMECHANGED](https://learn.microsoft.com/en-us/windows/win32/winmsg/wm-themechanged) states that applications should return zero if they process the message. I think it's good practice to do so, as otherwise Windows wouldn't be aware that we processed the message, causing potential behavioral changes if the default window procedure is changed in future OS releases. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1412691479 From mstrauss at openjdk.org Sat Dec 2 01:43:52 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 2 Dec 2023 01:43:52 GMT Subject: RFR: 8301302: Platform preferences API [v37] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: check for pending exceptions in Windows PlatformSupport ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/0572a363..f291ea48 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=36 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=35-36 Stats: 54 lines in 1 file changed: 34 ins; 0 del; 20 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From nlisker at gmail.com Sat Dec 2 04:35:15 2023 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 2 Dec 2023 06:35:15 +0200 Subject: CssMetaData.combine() In-Reply-To: <154ba5f4-06d7-9832-0bcc-0dc2c5680ddd@gmail.com> References: <154ba5f4-06d7-9832-0bcc-0dc2c5680ddd@gmail.com> Message-ID: John answered already to most of the points, but I want to give my own insights as well. > Even though the syntax is ugly, the current implementation of the static > getClassCssMetaData() is *nearly perfect*, considering the lack of some > kind of a 'lazy' keyword in java. > I don't buy Nir's argument about "questionable API". The API is codified > by Node.getCssMetaData() and the current implementation will be perfect > with the proposed utility method Let's look at what implementation is required from a user who wants to write their own styleable control: 1. Create styleable properties. 2. Create a list of these properties to be passed on. 3. Create a public static method that returns the concatenation of this list with the one of its parent. (This method happens to be poorly documented, as mstr said.) 4. Create a public non-static method that calls the static method in a forced-override pattern because otherwise you will be calling the wrong static method. (This method's docs seem to be just wrong because you don't always want to delegate to Node's list.) This is mostly redundant work with copy-paste and pitfalls, especially the need to manually specify the parent. I would say that this is a very cumbersome implementation that would not pass code review. I'm not sure if users even need access to those styleable lists themselves, maybe for GUI builders/analyzers? Surely you don't need 2 methods that do the same thing, and both of those codify the API. What the current code does is two things - a lazy initialization, meaning > the code will get executed only when needed, and it has zero per-instance > overhead. I don't think anyone can suggest a better way of doing it. > I'm confused by the notion that this is important. We're talking about static data, that is, per class, not per instance. How many styleable classes do we intend to use in an application? 100? Are we talking about saving 1KB of memory or 1 millisecond of runtime? *Per instance* is important, *per class* is negligible. And why is the need for laziness? John also mentioned that any displayed instance of a class will initialize these anyway (on first use). A benefit can only arise if we create an instance but don't show it, in which case why did we create it? And I would be very much interested to hear from Nir his idea of an API > that is not questionable. I think we'll all benefit from learning how to > make javafx better. > Are we stuck with the current behavior of steps 2 to 4 above, or can we circumvent it for future cases? Do we only deal with controls here, or skins also because (as mentioned by John and Michael) they can also add styleable properties? If I had to touch the least amount of code, I would at least make the concatenating method auto-resolve the parent of the current class by calling `MethodHandles.lookup().lookupClass().getSuperclass()`, eliminating that pitfall. Then we don't need the static method as far as I can see since its whole purpose was to allow this recursive concatenation (except in cases like ContextMenuContext that do something weird). I think that a better overall approach could be with annotations on styleable properties and an annotation processor. It can have the following benefits: * Automatic access to the declared styleable properties. * Usable both in controls and in skins (or other classes). * Auto-generation of the css reference that is coupled with these. * Mention of the corresponding css attribute in their documentation (like I wanted previously https://mail.openjdk.org/pipermail/openjfx-dev/2022-February/033482.html). It will depend on what exactly we need to do with these properties. By the way, John Lazy initialization in many places that IMHO is not needed I noticed this for the first time in classes like Box, Sphere and Cylinder. Their dimension properties are lazily initialized, but are also initialized on construction, so I never understood what the point was. On Fri, Dec 1, 2023 at 5:57?AM John Hendrikx wrote: > Hi Andy, > > Let me start to say that I had no problem with this PR being merged as I > already agreed with one of the first versions. > > Sometimes then on the same PR there can be some discussions on what else > can be done in this area, potentially maybe even alleviating the need for > the change (X/Y problem, ie. why do you need this method? Because you need > to concatenate lists, but the underlying reason is that the CSS property > initialization is somewhat clumsy). > On 01/12/2023 01:11, Andy Goryachev wrote: > > Dear colleagues: > > > > there were a couple of comments after I withdrew > https://github.com/openjdk/jfx/pull/1296for reasons of frustration, so I > wanted to respond to those in the openjfx list. > > > > > I pondered that back when I was working on replacing these static > initializers with the .of collection variants. It doesn't work here for > problem stated above - we need to modify an unmodifiable list, which is why > I didn't touch them in that pass. While the proposed method is useful for > eliminating some ugly syntax, cementing a questionable API with more a > public API doesn't seem to me like the right direction. If the method is > made internal only, then that's fine. Alternatively, if the method is made > useful outside of this specific context, then even if it won't be used > here, it could be used in other places, and that's also fine. > > > > Even though the syntax is ugly, the current implementation of the static > getClassCssMetaData() is *nearly perfect*, considering the lack of some > kind of a 'lazy' keyword in java. > > It may be "nearly perfect" from an optimization viewpoint, but it is > clumsy and unwieldy for anyone wanting to implement CSS properties. > > > > What the current code does is two things - a lazy initialization, meaning > the code will get executed only when needed, and it has zero per-instance > overhead. I don't think anyone can suggest a better way of doing it. > > This was already mentioned on the PR, but I'll repeat it here: what is the > lazy initialization for? As soon as these Nodes need to be shown, all the > metadata will have been queried already. I don't see any benefit making > them lazy so you can create Nodes faster, as long as they are never shown. > > > > I don't buy Nir's argument about "questionable API". The API is codified > by Node.getCssMetaData() and the current implementation will be perfect > with the proposed utility method (and maybe we can address some other > comments from https://git.openjdk.org/jfx/pull/1293#discussion_r1411406802 > ). > > How can there be any doubt that this API is questionable? It ignores a > core feature of Java (inheritance) and moves this burden to the user by > calling static methods of its direct parent... in order to implement CSS > property **inheritance** -- it also burdens any subclass with the caching > of these properties (because "performance"), and to make those properties > publicly (and statically) available so another subclass might "inherit" > them. > > The API is clumsy enough that I loathe creating stylable properties for > the sheer amount of boilerplate that surrounds them. > > Some alternatives have been suggested, but are shot down without thinking > along to see if there might be something better possible here. Solutions > where some of the common logic is moved to either Node or the CSS subsystem > are certainly worth considering. > > > > > > ... a few bytes and cpu cycles would get saved ... > > This is not for you specifically, but JavaFX has a lot of "optimizations", > some resulting in really questionable patterns that have/are hurting us: > - Reimplementing core collection classes for some benefit, but then only > partially implementing them (and often buggy), and/or completely breaking > the collection contract [BitSet] > > - Lazy initialization in many places that IMHO is not needed (benchmark > should be time to show window, anything accessed before that need not be > lazy, and is likely counterproductive) > > - Using plain arrays in many places, with a lot of custom code that's > already available in some standard collection class or as a standard > pattern; the custom code often has untested edge cases that contain bugs > [ExpressionHelper] > > - Making things mutable; surely mutating something must always be faster > than having to create a new object? Except that if there's a lot of > duplication going on because these objects are unshareable (because > mutable), the cost/benefit is no longer so clear (but try to prove that > with a micro benchmark) [PseudoClassState / StyleClassSet] > > - Also see many usages of LinkedList, a class that if you'd never use it, > you'd be better off 99.999% of the time; use of that class should always be > explained in a comment, and proven to be better with a benchmark [too many > places to list] > > The list goes on; many of the optimizations I've seen would make sense for > C/C++, but not for Java. Now I don't mind some optimizations, but > practically none of them are documented (deviating from the standard path > always deserves an explanation for the next developer) and I suspect they > were never verified either. I've done extensive "optimization" before, > with benchmarks, and you'd be surprised what is actually faster, and what > makes no difference whatsoever -- even then, after benchmarking, if the > difference is small, it's best to use established patterns, as that's what > the JDK optimizes for. What is marginally faster now, may not be faster on > the next JDK, with a different GC, when run in a real application (caches > will be used differently), or on a completely different architecture. > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Sat Dec 2 06:08:52 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sat, 2 Dec 2023 07:08:52 +0100 Subject: CssMetaData.combine() In-Reply-To: References: <154ba5f4-06d7-9832-0bcc-0dc2c5680ddd@gmail.com> Message-ID: <7c324846-2920-ca1a-c8bb-4b55a258509e@gmail.com> On 02/12/2023 05:35, Nir Lisker wrote: > > Lazy initialization in many places that IMHO is not needed > > > I noticed this for the first time in classes like Box, Sphere and > Cylinder. Their dimension properties are lazily initialized, but are > also initialized on construction, so I never understood what the point > was. Yeah, those are good examples where the lazy initialization is counter productive :) We should be on the look out for such things and remove it where it's not beneficial. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Sat Dec 2 06:29:48 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 2 Dec 2023 06:29:48 GMT Subject: RFR: 8320359: ImageView: add styleable fitWidth, fitHeight, preserveRatio, smooth properties [v5] In-Reply-To: References: Message-ID: On Fri, 1 Dec 2023 19:03:23 GMT, Andy Goryachev wrote: >> Adding missing styleable properties to ImageView: >> >> >> -fx-preserve-ratio >> -fx-smooth >> -fx-fit-width >> -fx-fit-height >> >> >> Updated CSS Reference. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > list of Marked as reviewed by jhendrikx (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1293#pullrequestreview-1760789116 From john.hendrikx at gmail.com Sat Dec 2 07:21:35 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sat, 2 Dec 2023 08:21:35 +0100 Subject: ToggleButton behavior Message-ID: In my exploration of a potential Behavior API, I discovered this oddity in how ToggleButtons work. 1. If you have a single ToggleButton that is not part of a ToggleGroup, you can't navigate away from it with the arrow keys, only by using Tab or Shift-Tab. 2. If you have that same single ToggleButton, but it does have a group (a group of one) then you CAN navigate away from it with the arrow keys. 3. When you have two ToggleButtons, both part of the same group, then you can only navigate away from the group with Tab or Shift-Tab again, as the arrow keys will loop back to the first/last button when the end of the group is reached. I get the impression at least one of these is incorrect. I mean, either ToggleButtons should always loop, even if it is a group of one, meaning (2) would be incorrect... Or... ToggleButtons should never loop, in which case (1) and (3) are incorrect... Or... Single ToggleButtons (grouped or not) behave differently and don't do looping, in which case (1) is incorrect Thoughts? --John From john.hendrikx at gmail.com Sat Dec 2 10:06:36 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sat, 2 Dec 2023 11:06:36 +0100 Subject: Behavior API proof of concept PR In-Reply-To: References: <99ca55ba-72a7-809f-2340-9f3fffe60d53@gmail.com> <2c5318b7-178e-b834-aa6a-2d63f56699da@gmail.com> Message-ID: Hi list, I've done another update to the proof of concept PR for Behaviors, this time focusing a bit on allowing behavior extension.? I added a ToggleButtonBehavior that is an extension of a ButtonBaseBehavior. I tweaked some generics to make this possible, and changed a few API's slightly.? A ToggleButtonBehavior looks like this (relevant parts only): privatestaticfinalKeyHandler KEY_HANDLER; static{ SimpleKeyBinder keyBinder= newSimpleKeyBinder<>(); keyBinder.addBinding(newKeyCodeCombination(KeyCode.UP), c-> traverse(c, Direction.UP)); keyBinder.addBinding(newKeyCodeCombination(KeyCode.DOWN), c-> traverse(c, Direction.DOWN)); keyBinder.addBinding(newKeyCodeCombination(KeyCode.RIGHT), c-> traverse(c, Direction.RIGHT)); keyBinder.addBinding(newKeyCodeCombination(KeyCode.LEFT), c-> traverse(c, Direction.LEFT)); KEY_HANDLER= keyBinder; } @Override publicStateFactory configure(BehaviorInstaller installer) { installer.registerKeyHandler(KEY_HANDLER); returnButtonBaseBehavior.getInstance().configure(installer); } As you can see, all it takes to "inherit" the basic behavior from ButtonBase is to have it also configure the installer.? The ToggleButtonBehavior does not extend the ButtonBaseBehavior (although I think it could have, if you really wanted to). The PR is here: https://github.com/openjdk/jfx/pull/1265 There are some failing tests which I'll get around to fixing. Mostly tests which do nasty stuff like getting at internals like InputMap to do their verifications.? So far so good. --John On 01/12/2023 20:56, John Hendrikx wrote: > > I've updated the proof of concept PR, and it has a number of changes > to allow more reuse of the behaviors handlers and key bindings.? This > has resulted in the Behavior installation process to become a bit more > complex, but the actual use and the API's are still relatively > simple.? For example, SpinnerBehavior's configuration method now looks > like this: > > @Override > > publicStateFactory> configure(BehaviorInstaller> > installer) { > > installer.setKeyHandler(KEY_HANDLER); > > installer.registerEventHandler(MouseEvent.MOUSE_PRESSED, > State::mousePressed); > > installer.registerEventHandler(MouseEvent.MOUSE_RELEASED, > State::mouseReleased); > > installer.registerEventHandler(AccessibleActionEvent.TRIGGERED, > State::accessibleActionTriggered); > > installer.registerPropertyListener(Node::sceneProperty, > State::sceneChanged); > > returnState::new; > > } > > Changes: > - Renamed BehaviorContext to BehaviorInstaller to better reflect its > purpose > - Behaviors now configure the BehaviorInstaller, and provide a factory > for their State > ?? - This simplifies all the internal methods of Behaviors, no need > for a Control parameter everywhere anymore; State has a Control reference! > ?? - Because state and control are now provided at the same time, the > handlers can all be static and reusable > - Controls create a BehaviorInstaller, ask a Behavior to configure it, > then ask the installer to install the handlers on the control, > resulting in a Subscription to undo all changes later > ?? - This process, although a bit complex, ensures that Behaviors are > strictly limited in what changes they can apply to the control > ?? - The process also externalizes the Behavior's state, allowing its > handlers, listeners and key bindings to be reused accross controls > - Introduce a KeyHandler class, and a non-public helper > SimpleKeyBinder; these can be a precursor for an InputMap system > ?? - KeyHandler is fully static (or can be) to allow key binding reuse > ?? - Control can later be made responsible for handling InputMap style > overrides > > Note: earlier it was said that behaviors can be stateless, and this is > certainly true for the main Behavior type (which can be "set" on as > many controls as you'd like).? However, even Behaviors without "state" > still need the Control reference as a piece of state in order to do > anything at all.? So, no installed behaviors are actually stateless, > there is always at a minimum a control reference.? To better reflect > this, the State classes for the two proof of concept behaviors now are > constructed with a Control (to keep all the related state together), > allowing for easy access to the control for all its methods. > > The PR is here: https://github.com/openjdk/jfx/pull/1265 > > --John > > > On 30/11/2023 23:28, John Hendrikx wrote: >> >> Thanks for having a look! >> >> On 30/11/2023 19:47, Andy Goryachev wrote: >>> >>> I think BehaviorContext looks suspiciously like a (skin) input map, >>> so I would rather see that. >>> >>> Invention of State class is a way to work around the stateless >>> behavior which, though it adds (in my opinion) very little, might >>> still be a feature that app developers want to exploit - at least in >>> terms of saving on per-instance key maps.? So any alternative >>> proposal should also support a stateless behavior. >>> >> I'm unsure what you are trying to say here. >> >> The State class is internal, and can be anything, and take any form.? >> If you only need to add a single EventHandler, you can also make that >> a class instead of a Lambda and have the state there. The State >> class, which can be named anything, is just a convenient way to share >> state amongst multiple handlers without having to construct each of >> them with special parameters, or having to put the state in the main >> class's fields (which would make it not reusable). >> >> I do however see that I did not take reusability of the keymaps into >> account in this version, that will need to be adjusted -- I was more >> focused on keeping Behaviors isolated for now, not needing a Control >> until installed, and having 0 references between Skins and Behaviors. >> >> I was hoping for more comments on how the seperation between Skin and >> Behavior is done in this PR.? I will attempt to adjust >> TextInputControl soon (and I will try a few subclasses of >> ButtonBehavior, to see how they can be built "on top" of another >> behavior) -- so far I've not found any real problems with this approach. >> >> --John >> >>> *From: *openjfx-dev on behalf of John >>> Hendrikx >>> *Date: *Wednesday, November 29, 2023 at 14:54 >>> *To: *openjfx-dev at openjdk.org >>> *Subject: *Behavior API proof of concept PR >>> >>> For those still interested, I've updated >>> https://github.com/openjdk/jfx/pull/1265 with a replaced ButtonBehavior >>> and SpinnerBehavior, using concepts laid out in >>> https://gist.github.com/hjohn/c7b1bf9d4a4770b1b3ae854b20fbaa94 >>> >>> Any feedback is welcome, I think it's making progress, and the changes >>> required seem quite doable. >>> >>> The ability for Behaviors to intercept any event from its Control or >>> its >>> (named) children makes Behaviors a lot more powerful than earlier >>> proposals, allowing for completely new interactions without requiring >>> Skin changes. >>> >>> --John >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at martinfox.com Sun Dec 3 01:57:46 2023 From: martin at martinfox.com (Martin Fox) Date: Sat, 2 Dec 2023 17:57:46 -0800 Subject: ToggleButton behavior In-Reply-To: References: Message-ID: <487069A6-3B53-4EF7-A21E-D1A86474A1ED@martinfox.com> I took a look at the W3C accessibility guidelines for radio button groups since that?s the closest thing I could find to a group of ToggleButtons. The W3C suggests that Tab/Shift+Tab takes you in and out of the group and the arrow keys navigate within the group with wrap-around. Based on that (3) is correct. That?s where the W3C guidance ends; a single radio button doesn?t make much sense so it?s not even mentioned. I would expect a single ungrouped ToggleButton to navigate like a checkbox so (1) seems wrong. A group with just one ToggleButton is an odd thing so (2) could go either way. Martin > On Dec 1, 2023, at 11:21?PM, John Hendrikx wrote: > > In my exploration of a potential Behavior API, I discovered this oddity in how ToggleButtons work. > > 1. If you have a single ToggleButton that is not part of a ToggleGroup, you can't navigate away from it with the arrow keys, only by using Tab or Shift-Tab. > > 2. If you have that same single ToggleButton, but it does have a group (a group of one) then you CAN navigate away from it with the arrow keys. > > 3. When you have two ToggleButtons, both part of the same group, then you can only navigate away from the group with Tab or Shift-Tab again, as the arrow keys will loop back to the first/last button when the end of the group is reached. > > I get the impression at least one of these is incorrect. > > I mean, either ToggleButtons should always loop, even if it is a group of one, meaning (2) would be incorrect... > > Or... ToggleButtons should never loop, in which case (1) and (3) are incorrect... > > Or... Single ToggleButtons (grouped or not) behave differently and don't do looping, in which case (1) is incorrect > > Thoughts? > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsayao at openjdk.org Sun Dec 3 21:02:54 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 3 Dec 2023 21:02:54 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v13] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 23:54:09 GMT, Andy Goryachev wrote: >> Copying and pasting Chinese characters on a JavaFX app on 23.10 is also broken, so It seems a problem somewhere else other than IME-related. > >> Copying and pasting Chinese characters on a JavaFX app on 23.10 is also broken > > is this an ubuntu or javafx problem? @andy-goryachev-oracle It seems to be a javafx problem. Copying ? and pasting into a TextArea produces a "square" symbol while pasting on gnome editor produces the correct symbol. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1837598662 From tsayao at openjdk.org Sun Dec 3 22:37:48 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 3 Dec 2023 22:37:48 GMT Subject: RFR: 8319340: [Linux] Disabled windows should not allow window operations (minimize, resize, maximize, close) [v2] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 10:34:42 GMT, Thiago Milczarek Sayao wrote: >> JavaFX on Linux is allowing disabled windows to be minimized. >> >> Currently close does nothing as it should, maximize disappears (on MS Windows it's greyed out - it's a platform behavior difference) and minimize is being allowed. >> >> Thins PR removes WM functions when window is disabled and restores it back when it's re-enabled. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Leave the Close button so it does not look too weird. I've tried the `_NET_WM_ALLOWED_ACTIONS` but it has no effect on mutter. I don't like this solution, but It seems there are no options. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1278#issuecomment-1837621817 From arapte at openjdk.org Mon Dec 4 05:00:52 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 4 Dec 2023 05:00:52 GMT Subject: [jfx21u] Integrated: 8318708: FX: Update copyright year in docs, readme files to 2024 In-Reply-To: References: Message-ID: On Fri, 1 Dec 2023 10:57:43 GMT, Ambarish Rapte wrote: > A clean backport to jfx21u, to update copyright year in doc files. This pull request has now been integrated. Changeset: d7b5c1bf Author: Ambarish Rapte URL: https://git.openjdk.org/jfx21u/commit/d7b5c1bff2dac09b31d3cd79591c0d2009d6439a Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8318708: FX: Update copyright year in docs, readme files to 2024 Backport-of: 2aa69e0120976c77df35adcdb4908df1b55f8281 ------------- PR: https://git.openjdk.org/jfx21u/pull/36 From arapte at openjdk.org Mon Dec 4 05:14:48 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 4 Dec 2023 05:14:48 GMT Subject: RFR: 8284544: [Win] Name-Property of Spinner cannot be changed [v3] In-Reply-To: References: <3oqCt0wtfoCmhSJBJ06FrL8jMdW1BZr0vB3hD3YTxG8=.80674ba3-cc82-4773-87ef-fc981c3889b4@github.com> Message-ID: <0f4VmIBGIncGq1DIcumeRZxQ2N7mb5yELiB5vqW_TCQ=.08adce1f-db8d-4f08-8418-5ecec7a82889@github.com> On Fri, 1 Dec 2023 23:34:12 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> Mac a11y change for VALUE_STRING attribute for Spinner > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java line 805: > >> 803: break; >> 804: case VALUE_STRING: >> 805: if (getAttribute(ROLE) == AccessibleRole.SPINNER) { > > Why qualify this by the AccessibleRole? Might there be other controls in the future that report `VALUE_STRING`? Yes Kevin, as of now VALUE_STRING is only used for Spinner, but it's a pattern that is followed in this file: If anything is specific to a control we check the role. It also helps in finding code specific to a control. Let's please keep the check. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1291#discussion_r1413379685 From michaelstrau2 at gmail.com Mon Dec 4 06:02:00 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 4 Dec 2023 07:02:00 +0100 Subject: Reflective discovery of styleable properties Message-ID: Following up the discussion around the CssMetaData API, I'd like to chime in with yet another idea. To recap, here's Nir's summary of the current API [0]: "Let's look at what implementation is required from a user who wants to write their own styleable control: 1. Create styleable properties. 2. Create a list of these properties to be passed on. 3. Create a public static method that returns the concatenation of this list with the one of its parent. (This method happens to be poorly documented, as mstr said.) 4. Create a public non-static method that calls the static method in a forced-override pattern because otherwise you will be calling the wrong static method. (This method's docs seem to be just wrong because you don't always want to delegate to Node's list.)" I think this could reasonably be replaced with the following implementation requirements: 1. Create styleable properties. 2. That's it. Let's look at what we're actually trying to do: create a list of CSS-styleable property metadata of a class. But we can easily do that without all of the boilerplate code. When ?Node.getCssMetaData()` is invoked, all public methods of the class are reflectively enumerated, and metadata is retrieved from `Property` and `StyleableProperty` getters. This is a price that's only paid once for any particular class (i.e. not for every instance). The resulting metadata list is cached and reused for all instances of that particular class. As a further optimization, metadata lists are also cached and deduplicated for Control/Skin combinations (currently every Control instance has its own copy of the metadata list). Another benefit of this approach is that the CssMetaData can now be co-located with the property implementation, and not be kept around in other parts of the source code file. Here's how that looks like when a new "myValue" property is added to MyClass: StyleableDoubleProperty myValue = new SimpleStyleableDoubleProperty(this, "myValue") { static final CssMetaData METADATA = new CssMetaData( "-fx-my-value", SizeConverter.getInstance(), USE_COMPUTED_SIZE) { @Override public boolean isSettable(MyClass node) { return !node.myValue.isBound(); } @Override public StyleableProperty getStyleableProperty( MyClass node) { return node.myValue; } }; @Override public CssMetaData getCssMetaData() { return METADATA; } }; public final DoubleProperty myValueProperty() { return myValue; } It is not required to override the `getCssMetaData()` method, nor is it required to redeclare a new static `getClassCssMetaData()` method. It is also not required to manually keep the list of styleable properties in sync with the list of CSS metadata. I've prototyped this concept for the `Node`, `Region` and `Control` classes [1]. [0] https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044046.html [1] https://github.com/openjdk/jfx/pull/1299 From nlisker at openjdk.org Mon Dec 4 06:15:48 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 4 Dec 2023 06:15:48 GMT Subject: Integrated: 8314597: Deprecate for removal protected access methods in converters In-Reply-To: References: Message-ID: <5lasETVVYFAyVzARa-4dSuI3N1WPFydxbUXVd_is0sI=.5a8dd307-4296-4402-8af7-8af377c686d9@github.com> On Tue, 21 Nov 2023 21:11:43 GMT, Nir Lisker wrote: > Deprecating for removal `getDateFormat()` in `TimeStringConverter` and `DateStringConverter` after it was removed already in `DateTimeStringConverter`, and `getNumberFormat()` in `NumberStringConverter` (and subclasses). This pull request has now been integrated. Changeset: 092d5d2d Author: Nir Lisker URL: https://git.openjdk.org/jfx/commit/092d5d2d03feaaf51254d1e0c40238574df72325 Stats: 27 lines in 6 files changed: 18 ins; 0 del; 9 mod 8314597: Deprecate for removal protected access methods in converters Reviewed-by: angorya, jhendrikx, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1294 From arapte at openjdk.org Mon Dec 4 06:46:11 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 4 Dec 2023 06:46:11 GMT Subject: [jfx21u] RFR: 8318714: Update copyright header for files modified in 2023 Message-ID: Update Copyright year in files modified in year 2023. ------------- Commit messages: - backport 8318714 Changes: https://git.openjdk.org/jfx21u/pull/38/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=38&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318714 Stats: 44 lines in 44 files changed: 0 ins; 0 del; 44 mod Patch: https://git.openjdk.org/jfx21u/pull/38.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/38/head:pull/38 PR: https://git.openjdk.org/jfx21u/pull/38 From kcr at openjdk.org Mon Dec 4 15:56:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 4 Dec 2023 15:56:49 GMT Subject: [jfx21u] RFR: 8318714: Update copyright header for files modified in 2023 In-Reply-To: References: Message-ID: On Mon, 4 Dec 2023 06:39:47 GMT, Ambarish Rapte wrote: > Update Copyright year in files modified in year 2023. Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx21u/pull/38#pullrequestreview-1762790881 From andy.goryachev at oracle.com Mon Dec 4 16:34:44 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 4 Dec 2023 16:34:44 +0000 Subject: eclipse warnings Message-ID: Dear colleagues: Imported the openjfx project into another workspace with a more stringent error checking and discovered a few issues: * potential null pointer access: 295 * unnecessary cast or instanceof: 190 * redundant null check: 61 Do we want to clean these up? -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Mon Dec 4 16:57:00 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 4 Dec 2023 16:57:00 GMT Subject: [jfx21u] Integrated: 8318714: Update copyright header for files modified in 2023 In-Reply-To: References: Message-ID: On Mon, 4 Dec 2023 06:39:47 GMT, Ambarish Rapte wrote: > Update Copyright year in files modified in year 2023. This pull request has now been integrated. Changeset: a993b200 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx21u/commit/a993b20052ef561bd3b1958b1bd20f99ca562b05 Stats: 44 lines in 44 files changed: 0 ins; 0 del; 44 mod 8318714: Update copyright header for files modified in 2023 Reviewed-by: kcr Backport-of: bce15aa9e4c3e454a20ac17840f7abfe641ddc9c ------------- PR: https://git.openjdk.org/jfx21u/pull/38 From kevin.rushforth at oracle.com Mon Dec 4 17:04:59 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 4 Dec 2023 09:04:59 -0800 Subject: eclipse warnings In-Reply-To: References: Message-ID: <24f4a015-4093-496b-81a1-0d972f9bd686@oracle.com> We did a few of these sort of cleanup fixes a year or so ago. In general, this sort of cleanup *might* be useful, but also causes some code churn and takes review cycles to ensure that there is no unintentional side effect. The last two might be OK cleanup tasks, but I wouldn't make them a high priority. Worth noting is that a seemingly redundant null check or instanceof check is not always a bad thing, so I wouldn't clean up all of them. The first group is the more interesting one. In some cases a potential null access can highlight actual bugs. However, I oppose any automated solution for these, since adding a null check where you don't expect a null (even if you IDE thinks it might be possible) can hide the root cause of a problem. We aren't going to enforce these, though, so you'll likely need to configure your IDE to be less picky. -- Kevin On 12/4/2023 8:34 AM, Andy Goryachev wrote: > > Dear colleagues: > > Imported the openjfx project into another workspace with a more > stringent error checking and discovered a few issues: > > * potential null pointer access: 295 > * unnecessary cast or instanceof: 190 > * redundant null check: 61 > > Do we want to clean these up? > > -andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Mon Dec 4 17:12:50 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 4 Dec 2023 17:12:50 +0000 Subject: eclipse warnings In-Reply-To: <24f4a015-4093-496b-81a1-0d972f9bd686@oracle.com> References: <24f4a015-4093-496b-81a1-0d972f9bd686@oracle.com> Message-ID: The last two are just unnecessary code, I see no problems turning this warning off. But the 'potential null access' one, though being a bit overeager, might warrant a deeper scrutiny, as it might point to real bugs. I would suggest to turn this warning on and fix or mark the occurences with "SuppressWarning" where appropriate. But you do have a good point about review cycles. -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Monday, December 4, 2023 at 09:05 To: openjfx-dev at openjdk.org Subject: Re: eclipse warnings We did a few of these sort of cleanup fixes a year or so ago. In general, this sort of cleanup *might* be useful, but also causes some code churn and takes review cycles to ensure that there is no unintentional side effect. The last two might be OK cleanup tasks, but I wouldn't make them a high priority. Worth noting is that a seemingly redundant null check or instanceof check is not always a bad thing, so I wouldn't clean up all of them. The first group is the more interesting one. In some cases a potential null access can highlight actual bugs. However, I oppose any automated solution for these, since adding a null check where you don't expect a null (even if you IDE thinks it might be possible) can hide the root cause of a problem. We aren't going to enforce these, though, so you'll likely need to configure your IDE to be less picky. -- Kevin On 12/4/2023 8:34 AM, Andy Goryachev wrote: Dear colleagues: Imported the openjfx project into another workspace with a more stringent error checking and discovered a few issues: 1. potential null pointer access: 295 2. unnecessary cast or instanceof: 190 3. redundant null check: 61 Do we want to clean these up? -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Mon Dec 4 17:12:55 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 4 Dec 2023 17:12:55 GMT Subject: RFR: 8318388: Update libxslt to 1.1.39 [v2] In-Reply-To: <__VrzBWVNNYqsH9q-qh8aqW8Qob1j0drUiStyDsfufs=.f517d9a7-0fed-4de2-b56b-3a72b4f4d818@github.com> References: <__VrzBWVNNYqsH9q-qh8aqW8Qob1j0drUiStyDsfufs=.f517d9a7-0fed-4de2-b56b-3a72b4f4d818@github.com> Message-ID: On Thu, 30 Nov 2023 08:37:35 GMT, Hima Bindu Meda wrote: >> Updated libxslt to v1.1.39. Verified build on all platforms.No issue seen. > > Hima Bindu Meda has updated the pull request incrementally with two additional commits since the last revision: > > - update license for libxslt > - update libxslt.md Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1298#pullrequestreview-1762970749 From johan.vos at gluonhq.com Mon Dec 4 17:24:44 2023 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 4 Dec 2023 18:24:44 +0100 Subject: eclipse warnings In-Reply-To: <24f4a015-4093-496b-81a1-0d972f9bd686@oracle.com> References: <24f4a015-4093-496b-81a1-0d972f9bd686@oracle.com> Message-ID: Also, these commits often affect many files at once (in scattered locations), and that makes backports harder. - Johan On Mon, Dec 4, 2023 at 6:14?PM Kevin Rushforth wrote: > We did a few of these sort of cleanup fixes a year or so ago. > > In general, this sort of cleanup *might* be useful, but also causes some > code churn and takes review cycles to ensure that there is no unintentional > side effect. > > The last two might be OK cleanup tasks, but I wouldn't make them a high > priority. Worth noting is that a seemingly redundant null check or > instanceof check is not always a bad thing, so I wouldn't clean up all of > them. > > The first group is the more interesting one. In some cases a potential > null access can highlight actual bugs. However, I oppose any automated > solution for these, since adding a null check where you don't expect a null > (even if you IDE thinks it might be possible) can hide the root cause of a > problem. > > We aren't going to enforce these, though, so you'll likely need to > configure your IDE to be less picky. > > -- Kevin > > > On 12/4/2023 8:34 AM, Andy Goryachev wrote: > > Dear colleagues: > > > > Imported the openjfx project into another workspace with a more stringent > error checking and discovered a few issues: > > > > - potential null pointer access: 295 > - unnecessary cast or instanceof: 190 > - redundant null check: 61 > > > > Do we want to clean these up? > > > > -andy > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Mon Dec 4 17:28:04 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 4 Dec 2023 09:28:04 -0800 Subject: eclipse warnings In-Reply-To: References: <24f4a015-4093-496b-81a1-0d972f9bd686@oracle.com> Message-ID: <7aafa744-87cb-417c-bb3d-2963cdba2a3d@oracle.com> Yes it might be worth looking at the possible null reference warnings. Maybe file an umbrella Task to look through the warnings and decide what to do with them? I don't think I like the "SuppressWarnings" as one of the remedies, but we can discuss that further once we have a list. -- Kevin On 12/4/2023 9:12 AM, Andy Goryachev wrote: > > The last two are just unnecessary code, I see no problems turning this > warning off. > > But the 'potential null access' one, though being a bit overeager, > might warrant a deeper scrutiny, as it might point to real bugs.? I > would suggest to turn this warning on and fix or mark the occurences > with "SuppressWarning" where appropriate. > > But you do have a good point about review cycles. > > -andy > > *From: *openjfx-dev on behalf of Kevin > Rushforth > *Date: *Monday, December 4, 2023 at 09:05 > *To: *openjfx-dev at openjdk.org > *Subject: *Re: eclipse warnings > > We did a few of these sort of cleanup fixes a year or so ago. > > In general, this sort of cleanup *might* be useful, but also causes > some code churn and takes review cycles to ensure that there is no > unintentional side effect. > > The last two might be OK cleanup tasks, but I wouldn't make them a > high priority. Worth noting is that a seemingly redundant null check > or instanceof check is not always a bad thing, so I wouldn't clean up > all of them. > > The first group is the more interesting one. In some cases a potential > null access can highlight actual bugs. However, I oppose any automated > solution for these, since adding a null check where you don't expect a > null (even if you IDE thinks it might be possible) can hide the root > cause of a problem. > > We aren't going to enforce these, though, so you'll likely need to > configure your IDE to be less picky. > > -- Kevin > > On 12/4/2023 8:34 AM, Andy Goryachev wrote: > > Dear colleagues: > > Imported the openjfx project into another workspace with a more > stringent error checking and discovered a few issues: > > 1. potential null pointer access: 295 > 2. unnecessary cast or instanceof: 190 > 3. redundant null check: 61 > > Do we want to clean these up? > > -andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Mon Dec 4 17:33:19 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 4 Dec 2023 09:33:19 -0800 Subject: [External] : Re: eclipse warnings In-Reply-To: References: <24f4a015-4093-496b-81a1-0d972f9bd686@oracle.com> Message-ID: <74e9149e-4d50-466a-b84d-4ca24bb06eed@oracle.com> Good point. -- Kevin On 12/4/2023 9:24 AM, Johan Vos wrote: > Also, these commits often affect many files at once (in scattered > locations), and that makes backports harder. > > - Johan > > On Mon, Dec 4, 2023 at 6:14?PM Kevin Rushforth > wrote: > > We did a few of these sort of cleanup fixes a year or so ago. > > In general, this sort of cleanup *might* be useful, but also > causes some code churn and takes review cycles to ensure that > there is no unintentional side effect. > > The last two might be OK cleanup tasks, but I wouldn't make them a > high priority. Worth noting is that a seemingly redundant null > check or instanceof check is not always a bad thing, so I wouldn't > clean up all of them. > > The first group is the more interesting one. In some cases a > potential null access can highlight actual bugs. However, I oppose > any automated solution for these, since adding a null check where > you don't expect a null (even if you IDE thinks it might be > possible) can hide the root cause of a problem. > > We aren't going to enforce these, though, so you'll likely need to > configure your IDE to be less picky. > > -- Kevin > > > On 12/4/2023 8:34 AM, Andy Goryachev wrote: >> >> Dear colleagues: >> >> Imported the openjfx project into another workspace with a more >> stringent error checking and discovered a few issues: >> >> * potential null pointer access: 295 >> * unnecessary cast or instanceof: 190 >> * redundant null check: 61 >> >> Do we want to clean these up? >> >> -andy >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Mon Dec 4 17:39:53 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 4 Dec 2023 18:39:53 +0100 Subject: eclipse warnings In-Reply-To: References: Message-ID: I also see lots of instances of a pattern where the the return value of a getter is checked, but then the getter is called again: if (getScene() != null) { getScene().getWindow() // and so on } While this generally works, we can't be 100% sure that this isn't potentially defective code (there could be side effects that cause the returned value to be different). Do we care about fixing that? On Mon, Dec 4, 2023 at 5:34?PM Andy Goryachev wrote: > > Dear colleagues: > > > > Imported the openjfx project into another workspace with a more stringent error checking and discovered a few issues: > > > > potential null pointer access: 295 > unnecessary cast or instanceof: 190 > redundant null check: 61 > > > > Do we want to clean these up? > > > > -andy > > From andy.goryachev at oracle.com Mon Dec 4 17:40:11 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 4 Dec 2023 17:40:11 +0000 Subject: CssMetaData.combine() In-Reply-To: References: <154ba5f4-06d7-9832-0bcc-0dc2c5680ddd@gmail.com> Message-ID: Thank you, Nir, for a thoughtful discussion. It looks like whatever requirement that resulted in a lazy initialization is not applicable anymore, or perhaps some later code changes in CssStyleHelper changed the design in such a way that the lazy initialization is no longer possible. The idea of using reflection or MethodHandlers.lookup().lookupClass().getSuperclass() is an interesting one. Would it work when reflection is disabled by the application? The reflection is sometimes disabled using a custom SecurityManager, though its days might be numbered. Once SecurityManager is removed, will there be a way for an application developer to disable reflection? I do like the idea about annotations, but there is still some amount of code in CssMetaData.isSettable(...) { ... property == null | !property.isBound() } so I am not sure if a pure annotation-based solution is possible (I could be wrong). What do you think? -andy From: openjfx-dev on behalf of Nir Lisker Date: Friday, December 1, 2023 at 20:35 To: John Hendrikx Cc: openjfx-dev at openjdk.org Subject: Re: CssMetaData.combine() John answered already to most of the points, but I want to give my own insights as well. Even though the syntax is ugly, the current implementation of the static getClassCssMetaData() is nearly perfect, considering the lack of some kind of a 'lazy' keyword in java. I don't buy Nir's argument about "questionable API". The API is codified by Node.getCssMetaData() and the current implementation will be perfect with the proposed utility method Let's look at what implementation is required from a user who wants to write their own styleable control: 1. Create styleable properties. 2. Create a list of these properties to be passed on. 3. Create a public static method that returns the concatenation of this list with the one of its parent. (This method happens to be poorly documented, as mstr said.) 4. Create a public non-static method that calls the static method in a forced-override pattern because otherwise you will be calling the wrong static method. (This method's docs seem to be just wrong because you don't always want to delegate to Node's list.) This is mostly redundant work with copy-paste and pitfalls, especially the need to manually specify the parent. I would say that this is a very cumbersome implementation that would not pass code review. I'm not sure if users even need access to those styleable lists themselves, maybe for GUI builders/analyzers? Surely you don't need 2 methods that do the same thing, and both of those codify the API. What the current code does is two things - a lazy initialization, meaning the code will get executed only when needed, and it has zero per-instance overhead. I don't think anyone can suggest a better way of doing it. I'm confused by the notion that this is important. We're talking about static data, that is, per class, not per instance. How many styleable classes do we intend to use in an application? 100? Are we talking about saving 1KB of memory or 1 millisecond of runtime? *Per instance* is important, *per class* is negligible. And why is the need for laziness? John also mentioned that any displayed instance of a class will initialize these anyway (on first use). A benefit can only arise if we create an instance but don't show it, in which case why did we create it? And I would be very much interested to hear from Nir his idea of an API that is not questionable. I think we'll all benefit from learning how to make javafx better. Are we stuck with the current behavior of steps 2 to 4 above, or can we circumvent it for future cases? Do we only deal with controls here, or skins also because (as mentioned by John and Michael) they can also add styleable properties? If I had to touch the least amount of code, I would at least make the concatenating method auto-resolve the parent of the current class by calling `MethodHandles.lookup().lookupClass().getSuperclass()`, eliminating that pitfall. Then we don't need the static method as far as I can see since its whole purpose was to allow this recursive concatenation (except in cases like ContextMenuContext that do something weird). I think that a better overall approach could be with annotations on styleable properties and an annotation processor. It can have the following benefits: * Automatic access to the declared styleable properties. * Usable both in controls and in skins (or other classes). * Auto-generation of the css reference that is coupled with these. * Mention of the corresponding css attribute in their documentation (like I wanted previously https://mail.openjdk.org/pipermail/openjfx-dev/2022-February/033482.html). It will depend on what exactly we need to do with these properties. By the way, John Lazy initialization in many places that IMHO is not needed I noticed this for the first time in classes like Box, Sphere and Cylinder. Their dimension properties are lazily initialized, but are also initialized on construction, so I never understood what the point was. On Fri, Dec 1, 2023 at 5:57?AM John Hendrikx > wrote: Hi Andy, Let me start to say that I had no problem with this PR being merged as I already agreed with one of the first versions. Sometimes then on the same PR there can be some discussions on what else can be done in this area, potentially maybe even alleviating the need for the change (X/Y problem, ie. why do you need this method? Because you need to concatenate lists, but the underlying reason is that the CSS property initialization is somewhat clumsy). On 01/12/2023 01:11, Andy Goryachev wrote: Dear colleagues: there were a couple of comments after I withdrew https://github.com/openjdk/jfx/pull/1296for reasons of frustration, so I wanted to respond to those in the openjfx list. > I pondered that back when I was working on replacing these static initializers with the .of collection variants. It doesn't work here for problem stated above - we need to modify an unmodifiable list, which is why I didn't touch them in that pass. While the proposed method is useful for eliminating some ugly syntax, cementing a questionable API with more a public API doesn't seem to me like the right direction. If the method is made internal only, then that's fine. Alternatively, if the method is made useful outside of this specific context, then even if it won't be used here, it could be used in other places, and that's also fine. Even though the syntax is ugly, the current implementation of the static getClassCssMetaData() is nearly perfect, considering the lack of some kind of a 'lazy' keyword in java. It may be "nearly perfect" from an optimization viewpoint, but it is clumsy and unwieldy for anyone wanting to implement CSS properties. What the current code does is two things - a lazy initialization, meaning the code will get executed only when needed, and it has zero per-instance overhead. I don't think anyone can suggest a better way of doing it. This was already mentioned on the PR, but I'll repeat it here: what is the lazy initialization for? As soon as these Nodes need to be shown, all the metadata will have been queried already. I don't see any benefit making them lazy so you can create Nodes faster, as long as they are never shown. I don't buy Nir's argument about "questionable API". The API is codified by Node.getCssMetaData() and the current implementation will be perfect with the proposed utility method (and maybe we can address some other comments from https://git.openjdk.org/jfx/pull/1293#discussion_r1411406802 ). How can there be any doubt that this API is questionable? It ignores a core feature of Java (inheritance) and moves this burden to the user by calling static methods of its direct parent... in order to implement CSS property **inheritance** -- it also burdens any subclass with the caching of these properties (because "performance"), and to make those properties publicly (and statically) available so another subclass might "inherit" them. The API is clumsy enough that I loathe creating stylable properties for the sheer amount of boilerplate that surrounds them. Some alternatives have been suggested, but are shot down without thinking along to see if there might be something better possible here. Solutions where some of the common logic is moved to either Node or the CSS subsystem are certainly worth considering. ... a few bytes and cpu cycles would get saved ... This is not for you specifically, but JavaFX has a lot of "optimizations", some resulting in really questionable patterns that have/are hurting us: - Reimplementing core collection classes for some benefit, but then only partially implementing them (and often buggy), and/or completely breaking the collection contract [BitSet] - Lazy initialization in many places that IMHO is not needed (benchmark should be time to show window, anything accessed before that need not be lazy, and is likely counterproductive) - Using plain arrays in many places, with a lot of custom code that's already available in some standard collection class or as a standard pattern; the custom code often has untested edge cases that contain bugs [ExpressionHelper] - Making things mutable; surely mutating something must always be faster than having to create a new object? Except that if there's a lot of duplication going on because these objects are unshareable (because mutable), the cost/benefit is no longer so clear (but try to prove that with a micro benchmark) [PseudoClassState / StyleClassSet] - Also see many usages of LinkedList, a class that if you'd never use it, you'd be better off 99.999% of the time; use of that class should always be explained in a comment, and proven to be better with a benchmark [too many places to list] The list goes on; many of the optimizations I've seen would make sense for C/C++, but not for Java. Now I don't mind some optimizations, but practically none of them are documented (deviating from the standard path always deserves an explanation for the next developer) and I suspect they were never verified either. I've done extensive "optimization" before, with benchmarks, and you'd be surprised what is actually faster, and what makes no difference whatsoever -- even then, after benchmarking, if the difference is small, it's best to use established patterns, as that's what the JDK optimizes for. What is marginally faster now, may not be faster on the next JDK, with a different GC, when run in a real application (caches will be used differently), or on a completely different architecture. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Mon Dec 4 17:47:35 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 4 Dec 2023 17:47:35 +0000 Subject: eclipse warnings In-Reply-To: References: Message-ID: This might be different. If we can guarantee that the access to the underlying variable(s) is single threaded - then no. But we had at least one bug recently in JFXPanel where two threads were involved. Those cases need to use a very different access pattern(s), depending on the exact circumstances. -andy From: openjfx-dev on behalf of Michael Strau? Date: Monday, December 4, 2023 at 09:40 To: Cc: openjfx-dev at openjdk.org Subject: Re: eclipse warnings I also see lots of instances of a pattern where the the return value of a getter is checked, but then the getter is called again: if (getScene() != null) { getScene().getWindow() // and so on } While this generally works, we can't be 100% sure that this isn't potentially defective code (there could be side effects that cause the returned value to be different). Do we care about fixing that? On Mon, Dec 4, 2023 at 5:34?PM Andy Goryachev wrote: > > Dear colleagues: > > > > Imported the openjfx project into another workspace with a more stringent error checking and discovered a few issues: > > > > potential null pointer access: 295 > unnecessary cast or instanceof: 190 > redundant null check: 61 > > > > Do we want to clean these up? > > > > -andy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Mon Dec 4 17:55:11 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 4 Dec 2023 18:55:11 +0100 Subject: eclipse warnings In-Reply-To: References: Message-ID: Side effects are not limited to race conditions. A getter might return a different value every time, or it might execute code other than simply returning a value, or a lazy evaluation scheme might cause other code to be executed. The point is, we don't know that at the call site, we'd need to inspect what the getter actually does. On Mon, Dec 4, 2023 at 6:47?PM Andy Goryachev wrote: > > This might be different. > > > > If we can guarantee that the access to the underlying variable(s) is single threaded - then no. But we had at least one bug recently in JFXPanel where two threads were involved. Those cases need to use a very different access pattern(s), depending on the exact circumstances. > > > > -andy From andy.goryachev at oracle.com Mon Dec 4 17:59:44 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 4 Dec 2023 17:59:44 +0000 Subject: eclipse warnings In-Reply-To: References: Message-ID: Yep, that's exactly my point. One may argue that using a local variable might help. I don't think there is a warning for this kind of code pattern though. -andy From: openjfx-dev on behalf of Michael Strau? Date: Monday, December 4, 2023 at 09:55 To: Cc: openjfx-dev at openjdk.org Subject: Re: eclipse warnings Side effects are not limited to race conditions. A getter might return a different value every time, or it might execute code other than simply returning a value, or a lazy evaluation scheme might cause other code to be executed. The point is, we don't know that at the call site, we'd need to inspect what the getter actually does. On Mon, Dec 4, 2023 at 6:47?PM Andy Goryachev wrote: > > This might be different. > > > > If we can guarantee that the access to the underlying variable(s) is single threaded - then no. But we had at least one bug recently in JFXPanel where two threads were involved. Those cases need to use a very different access pattern(s), depending on the exact circumstances. > > > > -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Mon Dec 4 21:52:52 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 4 Dec 2023 21:52:52 GMT Subject: Integrated: 8320359: ImageView: add styleable fitWidth, fitHeight, preserveRatio, smooth properties In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 00:01:14 GMT, Andy Goryachev wrote: > Adding missing styleable properties to ImageView: > > > -fx-preserve-ratio > -fx-smooth > -fx-fit-width > -fx-fit-height > > > Updated CSS Reference. This pull request has now been integrated. Changeset: aedc8879 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/aedc887922cb21fd4157048893e3543b2b288ae8 Stats: 242 lines in 4 files changed: 185 ins; 18 del; 39 mod 8320359: ImageView: add styleable fitWidth, fitHeight, preserveRatio, smooth properties Reviewed-by: mstrauss, jhendrikx, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1293 From kcr at openjdk.org Mon Dec 4 22:00:26 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 4 Dec 2023 22:00:26 GMT Subject: RFR: 8301302: Platform preferences API [v34] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <8o9x6e7VeMb2TaHyVlClUwpu6Bnn3W9OFPAz1KMPy7Q=.247637f1-473d-40ef-8cad-f1d555b5c782@github.com> Message-ID: On Sat, 2 Dec 2023 00:58:28 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/native-glass/gtk/PlatformSupport.cpp line 68: >> >>> 66: jobject PlatformSupport::collectPreferences() const { >>> 67: jobject prefs = env->NewObject(jHashMapCls, jHashMapInit); >>> 68: if (EXCEPTION_OCCURED(env)) return NULL; >> >> You should also check for `prefs == NULL` (or `!prefs` as you prefer); > > Is that necessary? The JNI documentation for `NewObject` states: "Returns a Java object, or NULL if the object cannot be constructed." > Is there a non-exceptional way to _not_ construct an instance of a class? I double-checked this with a few experts in this area. The [JNI NewStringUTF](https://docs.oracle.com/en/java/javase/21/docs/specs/jni/functions.html#newstringutf) spec states that it returns a Java string object, or `NULL` if the string cannot be constructed, and throws an exception if the system runs out of memory. Also, the [Java Exceptions section](https://docs.oracle.com/en/java/javase/21/docs/specs/jni/design.html#java-exceptions) in the JNI design overview says that you can check for an error return value and be assured that a non-error value means that no exceptions have been thrown. So the above means that if an exception is thrown, the ojbect will definitely be NULL. By itself, that doesn't necessarily guarantee the converse, but I don't know of any cases (and no one I asked did, either) where it would be possible for the `NewString*`, `NewObject*`, or `NewArray` functions to return null without throwing an exception. Having said that, most of our code that checks the return value checks for `NULL`, so I think checking for NULL would be a better pattern, but as long as you check for one or the other, I won't insist on it. Since this now isn't a case of missing error checking, but rather a code consistency issue (and we have other places where we do exactly what you propose to do), we might file a cleanup task to look into making our checks more consistent, but that would be after we take care of the functional problems we have around missing checks. >> modules/javafx.graphics/src/main/native-glass/gtk/PlatformSupport.cpp line 70: >> >>> 68: if (EXCEPTION_OCCURED(env)) return NULL; >>> 69: >>> 70: GtkStyle* style = gtk_style_new(); >> >> Can `gtk_style_new` return NULL? > > It's not specified to do so. Internally, it will call `g_object_new`, which is also not specified to return null. I've found some evidence on some gnome.org blog that it will not ever return null, but I haven't looked further than that. I suspect that any object allocation method, such as `g_object_new` could return null if memory is exhausted, so a NULL check seems like a good idea. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1414548560 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1414551756 From kcr at openjdk.org Mon Dec 4 22:00:24 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 4 Dec 2023 22:00:24 GMT Subject: RFR: 8301302: Platform preferences API [v37] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Sat, 2 Dec 2023 01:43:52 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > check for pending exceptions in Windows PlatformSupport I left comments about the NULL checks. I'll review the changes you made plus the files I haven't reviewed yet. ------------- PR Review: https://git.openjdk.org/jfx/pull/1014#pullrequestreview-1763503444 From mstrauss at openjdk.org Mon Dec 4 23:52:59 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 4 Dec 2023 23:52:59 GMT Subject: RFR: 8301302: Platform preferences API [v38] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: check for null return values of JNI methods ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/f291ea48..a04a8c6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=37 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=36-37 Stats: 9 lines in 2 files changed: 4 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Mon Dec 4 23:55:33 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 4 Dec 2023 23:55:33 GMT Subject: RFR: 8301302: Platform preferences API [v39] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: check return value of JNI functions ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/a04a8c6b..0dff7a49 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=38 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=37-38 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Tue Dec 5 00:12:15 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 5 Dec 2023 00:12:15 GMT Subject: RFR: 8301302: Platform preferences API [v37] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Mon, 4 Dec 2023 21:57:23 GMT, Kevin Rushforth wrote: > I left comments about the NULL checks. I'll review the changes you made plus the files I haven't reviewed yet. I've added the suggested null checks for all New* JNI functions, as well as for `gtk_style_new`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1839777202 From kpk at openjdk.org Tue Dec 5 04:46:44 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 5 Dec 2023 04:46:44 GMT Subject: RFR: 8282290: TextField Cursor Position one off [v3] In-Reply-To: <3O0CgH2CRPXmxTsFHviBRSFqbKn2s6H_7LLSKHtExSw=.1534fb3e-1648-4d83-930f-e3010c5bed62@github.com> References: <3O0CgH2CRPXmxTsFHviBRSFqbKn2s6H_7LLSKHtExSw=.1534fb3e-1648-4d83-930f-e3010c5bed62@github.com> Message-ID: On Fri, 1 Dec 2023 14:28:43 GMT, Karthik P K wrote: >> The change listener on caretPositionProperty() was not getting invoked on replacing the content with same text as there was no change in caret position. Since the textProperty invalidation sets the forward bias to true by default, incorrect caret position was calculated when the same text was replaced after clicking on the trailing edge of last character or empty space in the TextField. >> >> Since caretShapeProperty invalidation listener gets invoked without changing the caret position, updating the caretBiasProperty on this listener solves the issue. >> >> Since the caret position value will be same when the caret is present after the last character or before the last character, it can not be validated using unit test. >> The fix can be validated using MonkeyTester. >> Steps to select TextField option in Monkey Tester. >> >> - Open the MonkeyTester app and select TextField from the left option pane. >> - Select Short from Text selection option and click on the TextField to bring it into focus. >> - Select all using cmd(ctrl) + a and copy using cmd(ctrl) + c >> - Click on empty space in the TextField after the present content. >> - Select all again using the keyboard shortcut and paste using cmd(ctrl) + v >> - The caret should be displayed after the last character. Without the fix caret gets displayed before the last character. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Review comments @Maran23 could you please re-review? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1287#issuecomment-1839997594 From sykora at openjdk.org Tue Dec 5 07:21:45 2023 From: sykora at openjdk.org (Joeri Sykora) Date: Tue, 5 Dec 2023 07:21:45 GMT Subject: RFR: 8318388: Update libxslt to 1.1.39 [v2] In-Reply-To: <__VrzBWVNNYqsH9q-qh8aqW8Qob1j0drUiStyDsfufs=.f517d9a7-0fed-4de2-b56b-3a72b4f4d818@github.com> References: <__VrzBWVNNYqsH9q-qh8aqW8Qob1j0drUiStyDsfufs=.f517d9a7-0fed-4de2-b56b-3a72b4f4d818@github.com> Message-ID: On Thu, 30 Nov 2023 08:37:35 GMT, Hima Bindu Meda wrote: >> Updated libxslt to v1.1.39. Verified build on all platforms.No issue seen. > > Hima Bindu Meda has updated the pull request incrementally with two additional commits since the last revision: > > - update license for libxslt > - update libxslt.md Marked as reviewed by sykora (Author). ------------- PR Review: https://git.openjdk.org/jfx/pull/1298#pullrequestreview-1764114186 From nlisker at gmail.com Tue Dec 5 08:28:49 2023 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 5 Dec 2023 10:28:49 +0200 Subject: JavaFX and Panama Message-ID: Hi all, Panama's 'foreign' API will be released in JDK 22 [1][2]. It includes 'foreign memory' API for managing off-heap java memory, and 'foreign function' API for calling native functions. These replace some sun.misc.unsafe operations and all JNI. We should start allowing developers to use the new APIs as they greatly improve many aspects of the code (safer, simpler and possibly more performant). I have used the foreign function API in other projects since its incubation period (Java 18 or 19) and I can say that it works well and causes much less headache than JNI, although I didn't do a performance comparison in those cases. We should also think about replacing code with the new API. JavaFX uses sun.miscs.Unsafe in MarlinFX, and JNI is used extensively. While it's unreasonable (and at this point undesirable due to manpower constraints) to replace all of JNI, there are places where this approach should be looked at. The use of Unsafe also emits warnings, which we are trying to avoid. I therefore propose that JavaFX 23 bump its Java requirement to 22, maintaining the "N-1 guarantee". I think that this is a significant enough addition that merits this version bump, and will also bring with it all the previous features starting with Java 18, out of which some useful ones are: * Code Snippets [3] (18) * Record Patterns [4] (21) * Pattern Matching for switch [5] (21) * Unnamed Variables & Patterns [6] (22) We can start using the new APIs once the jfx 22 branch is split from the master. - Nir [1] https://openjdk.org/jeps/454 [2] https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/lang/foreign/package-summary.html [3] https://openjdk.org/jeps/413 [4] https://openjdk.org/jeps/440 [5] https://openjdk.org/jeps/441 [6] https://openjdk.org/jeps/456 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Tue Dec 5 08:54:55 2023 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 5 Dec 2023 10:54:55 +0200 Subject: eclipse warnings In-Reply-To: References: <24f4a015-4093-496b-81a1-0d972f9bd686@oracle.com> Message-ID: There's already ongoing work for this in https://bugs.openjdk.org/browse/JDK-8297300. John provided some fixes, I need to get back to it. On Mon, Dec 4, 2023 at 9:53?PM Johan Vos wrote: > Also, these commits often affect many files at once (in scattered > locations), and that makes backports harder. > > - Johan > > On Mon, Dec 4, 2023 at 6:14?PM Kevin Rushforth > wrote: > >> We did a few of these sort of cleanup fixes a year or so ago. >> >> In general, this sort of cleanup *might* be useful, but also causes some >> code churn and takes review cycles to ensure that there is no unintentional >> side effect. >> >> The last two might be OK cleanup tasks, but I wouldn't make them a high >> priority. Worth noting is that a seemingly redundant null check or >> instanceof check is not always a bad thing, so I wouldn't clean up all of >> them. >> >> The first group is the more interesting one. In some cases a potential >> null access can highlight actual bugs. However, I oppose any automated >> solution for these, since adding a null check where you don't expect a null >> (even if you IDE thinks it might be possible) can hide the root cause of a >> problem. >> >> We aren't going to enforce these, though, so you'll likely need to >> configure your IDE to be less picky. >> >> -- Kevin >> >> >> On 12/4/2023 8:34 AM, Andy Goryachev wrote: >> >> Dear colleagues: >> >> >> >> Imported the openjfx project into another workspace with a more stringent >> error checking and discovered a few issues: >> >> >> >> - potential null pointer access: 295 >> - unnecessary cast or instanceof: 190 >> - redundant null check: 61 >> >> >> >> Do we want to clean these up? >> >> >> >> -andy >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpereda at openjdk.org Tue Dec 5 09:47:28 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Dec 2023 09:47:28 GMT Subject: [jfx17u] RFR: 8201538: Remove implementation support for applets from JavaFX Message-ID: Clean backport of 8201538: Remove implementation support for applets from JavaFX Reviewed-by: mstrauss, aghaisas, jvos ------------- Commit messages: - 8201538: Remove implementation support for applets from JavaFX Changes: https://git.openjdk.org/jfx17u/pull/169/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=169&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8201538 Stats: 3424 lines in 64 files changed: 32 ins; 3308 del; 84 mod Patch: https://git.openjdk.org/jfx17u/pull/169.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/169/head:pull/169 PR: https://git.openjdk.org/jfx17u/pull/169 From aghaisas at openjdk.org Tue Dec 5 10:02:48 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 5 Dec 2023 10:02:48 GMT Subject: RFR: 8284544: [Win] Name-Property of Spinner cannot be changed [v3] In-Reply-To: <3oqCt0wtfoCmhSJBJ06FrL8jMdW1BZr0vB3hD3YTxG8=.80674ba3-cc82-4773-87ef-fc981c3889b4@github.com> References: <3oqCt0wtfoCmhSJBJ06FrL8jMdW1BZr0vB3hD3YTxG8=.80674ba3-cc82-4773-87ef-fc981c3889b4@github.com> Message-ID: On Wed, 22 Nov 2023 17:05:36 GMT, Ambarish Rapte wrote: >> Currently we use the value of spinner as it's `UIA_NamePropertyId` when a11y client application requests for it. >> Ideally we should use the text set by `Node.setAccessibleText()` as the `UIA_NamePropertyId`. >> For other controls such as Slider, ListView we use the text set by setAccessibleText() API. >> >> Fix: >> Use the text set by `Node.setAccessibleText()` as the `UIA_NamePropertyId`. >> This means, when a11y client requests `UIA_NamePropertyId`, which is mapped to AccessibleAttribute.TEXT attribute, we shall return the accessible text. >> So we need another way to read out the VALUE of the Spinner. >> - For this we need to implement `IValueProvider` pattern for Spinner control >> - IValueProvider requests the value of the control using it's API `get_ValueString()` >> - It required to introduce a new AccessibleAttribute `VALUE_STRING` >> - IValueProvider also reads out if the control is editable or not, hence added `EDITABLE `case in `Spinner.queryAccessibleAttribute()` >> >> Verification: >> - Run any spinner app, with setAccessibleText set on spinner >> - Run Windows narrator and observe >> - Without this fix: >> - 1. Narrator does not read the text set by setAccessibleText >> - 2. In application "Accessibility Insights for Windows", you can see the value of Spinner as the Name property >> - After this fix: >> - 1. Narrator reads the accessible text then value of Spinner and then if editable or not >> - 2. In application "Accessibility Insights for Windows", you can see the text set by `setAccessibleText()` for Spinner as the Name property and the Spinner's value as value property > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Mac a11y change for VALUE_STRING attribute for Spinner The fix looks good! ------------- Marked as reviewed by aghaisas (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1291#pullrequestreview-1764608906 From hmeda at openjdk.org Tue Dec 5 10:27:54 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 5 Dec 2023 10:27:54 GMT Subject: Integrated: 8318388: Update libxslt to 1.1.39 In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 11:18:43 GMT, Hima Bindu Meda wrote: > Updated libxslt to v1.1.39. Verified build on all platforms.No issue seen. This pull request has now been integrated. Changeset: 09922d5c Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx/commit/09922d5c030aa4d82a477f2c1ca27de052f0543d Stats: 2658 lines in 49 files changed: 1069 ins; 1158 del; 431 mod 8318388: Update libxslt to 1.1.39 Reviewed-by: kcr, sykora ------------- PR: https://git.openjdk.org/jfx/pull/1298 From arapte at openjdk.org Tue Dec 5 10:42:53 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 5 Dec 2023 10:42:53 GMT Subject: Integrated: 8284544: [Win] Name-Property of Spinner cannot be changed In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 05:37:38 GMT, Ambarish Rapte wrote: > Currently we use the value of spinner as it's `UIA_NamePropertyId` when a11y client application requests for it. > Ideally we should use the text set by `Node.setAccessibleText()` as the `UIA_NamePropertyId`. > For other controls such as Slider, ListView we use the text set by setAccessibleText() API. > > Fix: > Use the text set by `Node.setAccessibleText()` as the `UIA_NamePropertyId`. > This means, when a11y client requests `UIA_NamePropertyId`, which is mapped to AccessibleAttribute.TEXT attribute, we shall return the accessible text. > So we need another way to read out the VALUE of the Spinner. > - For this we need to implement `IValueProvider` pattern for Spinner control > - IValueProvider requests the value of the control using it's API `get_ValueString()` > - It required to introduce a new AccessibleAttribute `VALUE_STRING` > - IValueProvider also reads out if the control is editable or not, hence added `EDITABLE `case in `Spinner.queryAccessibleAttribute()` > > Verification: > - Run any spinner app, with setAccessibleText set on spinner > - Run Windows narrator and observe > - Without this fix: > - 1. Narrator does not read the text set by setAccessibleText > - 2. In application "Accessibility Insights for Windows", you can see the value of Spinner as the Name property > - After this fix: > - 1. Narrator reads the accessible text then value of Spinner and then if editable or not > - 2. In application "Accessibility Insights for Windows", you can see the text set by `setAccessibleText()` for Spinner as the Name property and the Spinner's value as value property This pull request has now been integrated. Changeset: 43448ddc Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/43448ddc5f2eda15a892fd0ea38bae2b14b54296 Stats: 63 lines in 4 files changed: 55 ins; 4 del; 4 mod 8284544: [Win] Name-Property of Spinner cannot be changed Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/1291 From jpereda at openjdk.org Tue Dec 5 10:49:53 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Dec 2023 10:49:53 GMT Subject: [jfx17u] Integrated: 8201538: Remove implementation support for applets from JavaFX In-Reply-To: References: Message-ID: On Tue, 5 Dec 2023 09:39:59 GMT, Jose Pereda wrote: > Clean backport of 8201538: Remove implementation support for applets from JavaFX > Reviewed-by: mstrauss, aghaisas, jvos This pull request has now been integrated. Changeset: efbbfcf0 Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/efbbfcf0cacda72a9ef90e5495afc76f942eef79 Stats: 3424 lines in 64 files changed: 32 ins; 3308 del; 84 mod 8201538: Remove implementation support for applets from JavaFX Backport-of: 4f9b047b8301ee3580588dd34ab809f5c6c4c193 ------------- PR: https://git.openjdk.org/jfx17u/pull/169 From john.hendrikx at gmail.com Tue Dec 5 11:02:49 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 5 Dec 2023 12:02:49 +0100 Subject: eclipse warnings In-Reply-To: References: Message-ID: <3fdea815-67bc-f1c9-abca-02a46a1b39fd@gmail.com> When this runs on the FX thread it has to be safe, but it's not very nice. These days you can do these kind of null chain checks like this: ????? if (getScene() instanceof Scene s && s.getWindow() instanceof Window w && w.isShowing()) { ????? } --John On 04/12/2023 18:39, Michael Strau? wrote: > I also see lots of instances of a pattern where the the return value > of a getter is checked, but then the getter is called again: > > if (getScene() != null) { > getScene().getWindow() // and so on > } > > While this generally works, we can't be 100% sure that this isn't > potentially defective code (there could be side effects that cause the > returned value to be different). Do we care about fixing that? > > > > On Mon, Dec 4, 2023 at 5:34?PM Andy Goryachev wrote: >> Dear colleagues: >> >> >> >> Imported the openjfx project into another workspace with a more stringent error checking and discovered a few issues: >> >> >> >> potential null pointer access: 295 >> unnecessary cast or instanceof: 190 >> redundant null check: 61 >> >> >> >> Do we want to clean these up? >> >> >> >> -andy >> >> From john.hendrikx at gmail.com Tue Dec 5 11:06:18 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 5 Dec 2023 12:06:18 +0100 Subject: eclipse warnings In-Reply-To: References: Message-ID: <56ff98d4-bc56-5730-5e64-087cfae71163@gmail.com> There is an unwritten contract that getters should not have such side effects; IMHO if a getter is doing this, the getter is broken, and should not be named "getXXX".? Use something else like "find", "determine", "create" -- in other words, if a getter wants to do fancy tricks, that's fine, but it must be careful to ensure side effects don't influence the result. --John On 04/12/2023 18:55, Michael Strau? wrote: > Side effects are not limited to race conditions. A getter might return > a different value every time, or it might execute code other than > simply returning a value, or a lazy evaluation scheme might cause > other code to be executed. The point is, we don't know that at the > call site, we'd need to inspect what the getter actually does. > > > On Mon, Dec 4, 2023 at 6:47?PM Andy Goryachev wrote: >> This might be different. >> >> >> >> If we can guarantee that the access to the underlying variable(s) is single threaded - then no. But we had at least one bug recently in JFXPanel where two threads were involved. Those cases need to use a very different access pattern(s), depending on the exact circumstances. >> >> >> >> -andy From jpereda at openjdk.org Tue Dec 5 11:08:55 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Dec 2023 11:08:55 GMT Subject: [jfx17u] RFR: 8292922: [Linux] No more drag events when new Stage is created in drag handler Message-ID: Clean backport of 8292922: [Linux] No more drag events when new Stage is created in drag handler Reviewed-by: angorya, kcr ------------- Commit messages: - 8292922: [Linux] No more drag events when new Stage is created in drag handler Changes: https://git.openjdk.org/jfx17u/pull/170/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=170&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292922 Stats: 101 lines in 2 files changed: 10 ins; 88 del; 3 mod Patch: https://git.openjdk.org/jfx17u/pull/170.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/170/head:pull/170 PR: https://git.openjdk.org/jfx17u/pull/170 From john.hendrikx at gmail.com Tue Dec 5 11:16:29 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 5 Dec 2023 12:16:29 +0100 Subject: eclipse warnings In-Reply-To: References: Message-ID: <7c147924-7624-ec3f-b0ce-cface7740800@gmail.com> IMHO, there is no capacity for this. I did many warning fixes, and there are PR's outstanding with warning fixes, but they're not getting reviewed. There are other PR's outstanding that are more valuable, but are not getting reviewed. I feel we need to fix that first before we can endulge in warning fixes. As for the potential null pointer access, it's often a false positive; static analyzers have a hard time determining if a loop is entered at least once (or an if in that loop) and so will warn that a local can maybe be null if it was initalized inside a loop. --John On 04/12/2023 17:34, Andy Goryachev wrote: > > Dear colleagues: > > Imported the openjfx project into another workspace with a more > stringent error checking and discovered a few issues: > > * potential null pointer access: 295 > * unnecessary cast or instanceof: 190 > * redundant null check: 61 > > Do we want to clean these up? > > -andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Tue Dec 5 11:42:30 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 5 Dec 2023 12:42:30 +0100 Subject: Reflective discovery of styleable properties In-Reply-To: References: Message-ID: <3b540bd3-a812-4bf4-b7fa-4751acfa986b@gmail.com> It looks good, and IMHO would be a major clean up, and would simplify creating stylable properties for users tremendously. I see you added a public API in CssMetaData, but I think you can just leave that private in CssMetaDataCache.? Users won't need it, as they should no longer be overriding getCssMetaData.? Old implementations are backwards compatible, so they won't need it either. Any new Nodes/Controls need not (or should not) provide the static getClassCssMetaData or override getCssMetaData. +1 --John On 04/12/2023 07:02, Michael Strau? wrote: > Following up the discussion around the CssMetaData API, I'd like to > chime in with yet another idea. To recap, here's Nir's summary of the > current API [0]: > > "Let's look at what implementation is required from a user who wants > to write their own styleable control: > 1. Create styleable properties. > 2. Create a list of these properties to be passed on. > 3. Create a public static method that returns the concatenation of > this list with the one of its parent. (This method happens to be > poorly documented, as mstr said.) > 4. Create a public non-static method that calls the static method in a > forced-override pattern because otherwise you will be calling the > wrong static method. (This method's docs seem to be just wrong because > you don't always want to delegate to Node's list.)" > > > I think this could reasonably be replaced with the following > implementation requirements: > 1. Create styleable properties. > 2. That's it. > > Let's look at what we're actually trying to do: create a list of > CSS-styleable property metadata of a class. But we can easily do that > without all of the boilerplate code. > > When ?Node.getCssMetaData()` is invoked, all public methods of the > class are reflectively enumerated, and metadata is retrieved from > `Property` and `StyleableProperty` getters. This is a price that's > only paid once for any particular class (i.e. not for every instance). > The resulting metadata list is cached and reused for all instances of > that particular class. > > As a further optimization, metadata lists are also cached and > deduplicated for Control/Skin combinations (currently every Control > instance has its own copy of the metadata list). > > Another benefit of this approach is that the CssMetaData can now be > co-located with the property implementation, and not be kept around in > other parts of the source code file. Here's how that looks like when a > new "myValue" property is added to MyClass: > > StyleableDoubleProperty myValue = > new SimpleStyleableDoubleProperty(this, "myValue") { > > static final CssMetaData METADATA = > new CssMetaData( > "-fx-my-value", > SizeConverter.getInstance(), > USE_COMPUTED_SIZE) { > @Override > public boolean isSettable(MyClass node) { > return !node.myValue.isBound(); > } > > @Override > public StyleableProperty getStyleableProperty( > MyClass node) { > return node.myValue; > } > }; > > @Override > public CssMetaData getCssMetaData() { > return METADATA; > } > }; > > public final DoubleProperty myValueProperty() { > return myValue; > } > > It is not required to override the `getCssMetaData()` method, nor is > it required to redeclare a new static `getClassCssMetaData()` method. > It is also not required to manually keep the list of styleable > properties in sync with the list of CSS metadata. > > I've prototyped this concept for the `Node`, `Region` and `Control` classes [1]. > > [0] https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044046.html > [1] https://github.com/openjdk/jfx/pull/1299 From thiago.sayao at gmail.com Tue Dec 5 11:56:24 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 5 Dec 2023 08:56:24 -0300 Subject: Reflective discovery of styleable properties In-Reply-To: <3b540bd3-a812-4bf4-b7fa-4751acfa986b@gmail.com> References: <3b540bd3-a812-4bf4-b7fa-4751acfa986b@gmail.com> Message-ID: Hi, Reflection is probably already being used in JavaFX and I think it's probably fine, but there's the case of graalvm native compiled JavaFX apps. -- Thiago. Em ter., 5 de dez. de 2023 ?s 08:42, John Hendrikx escreveu: > It looks good, and IMHO would be a major clean up, and would simplify > creating stylable properties for users tremendously. > > I see you added a public API in CssMetaData, but I think you can just > leave that private in CssMetaDataCache. Users won't need it, as they > should no longer be overriding getCssMetaData. Old implementations are > backwards compatible, so they won't need it either. > > Any new Nodes/Controls need not (or should not) provide the static > getClassCssMetaData or override getCssMetaData. > > +1 > > --John > > On 04/12/2023 07:02, Michael Strau? wrote: > > Following up the discussion around the CssMetaData API, I'd like to > > chime in with yet another idea. To recap, here's Nir's summary of the > > current API [0]: > > > > "Let's look at what implementation is required from a user who wants > > to write their own styleable control: > > 1. Create styleable properties. > > 2. Create a list of these properties to be passed on. > > 3. Create a public static method that returns the concatenation of > > this list with the one of its parent. (This method happens to be > > poorly documented, as mstr said.) > > 4. Create a public non-static method that calls the static method in a > > forced-override pattern because otherwise you will be calling the > > wrong static method. (This method's docs seem to be just wrong because > > you don't always want to delegate to Node's list.)" > > > > > > I think this could reasonably be replaced with the following > > implementation requirements: > > 1. Create styleable properties. > > 2. That's it. > > > > Let's look at what we're actually trying to do: create a list of > > CSS-styleable property metadata of a class. But we can easily do that > > without all of the boilerplate code. > > > > When ?Node.getCssMetaData()` is invoked, all public methods of the > > class are reflectively enumerated, and metadata is retrieved from > > `Property` and `StyleableProperty` getters. This is a price that's > > only paid once for any particular class (i.e. not for every instance). > > The resulting metadata list is cached and reused for all instances of > > that particular class. > > > > As a further optimization, metadata lists are also cached and > > deduplicated for Control/Skin combinations (currently every Control > > instance has its own copy of the metadata list). > > > > Another benefit of this approach is that the CssMetaData can now be > > co-located with the property implementation, and not be kept around in > > other parts of the source code file. Here's how that looks like when a > > new "myValue" property is added to MyClass: > > > > StyleableDoubleProperty myValue = > > new SimpleStyleableDoubleProperty(this, "myValue") { > > > > static final CssMetaData METADATA = > > new CssMetaData( > > "-fx-my-value", > > SizeConverter.getInstance(), > > USE_COMPUTED_SIZE) { > > @Override > > public boolean isSettable(MyClass node) { > > return !node.myValue.isBound(); > > } > > > > @Override > > public StyleableProperty getStyleableProperty( > > MyClass node) { > > return node.myValue; > > } > > }; > > > > @Override > > public CssMetaData getCssMetaData() { > > return METADATA; > > } > > }; > > > > public final DoubleProperty myValueProperty() { > > return myValue; > > } > > > > It is not required to override the `getCssMetaData()` method, nor is > > it required to redeclare a new static `getClassCssMetaData()` method. > > It is also not required to manually keep the list of styleable > > properties in sync with the list of CSS metadata. > > > > I've prototyped this concept for the `Node`, `Region` and `Control` > classes [1]. > > > > [0] > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044046.html > > [1] https://github.com/openjdk/jfx/pull/1299 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpereda at openjdk.org Tue Dec 5 11:56:46 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Dec 2023 11:56:46 GMT Subject: [jfx17u] Integrated: 8292922: [Linux] No more drag events when new Stage is created in drag handler In-Reply-To: References: Message-ID: <2ojRUiVKqBPTxcOI-eucoMGxaQizPGqLuH007NH9Lz0=.82ec17b9-de82-4e6f-aea9-1886f647f09e@github.com> On Tue, 5 Dec 2023 11:02:14 GMT, Jose Pereda wrote: > Clean backport of 8292922: [Linux] No more drag events when new Stage is created in drag handler > > Reviewed-by: angorya, kcr This pull request has now been integrated. Changeset: d6b9c7ae Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/d6b9c7ae1b1bae1d440582d563597d05d4030ff5 Stats: 101 lines in 2 files changed: 10 ins; 88 del; 3 mod 8292922: [Linux] No more drag events when new Stage is created in drag handler Backport-of: a35c3bf78b86c57d6e80d592e99f16ab349b0d8c ------------- PR: https://git.openjdk.org/jfx17u/pull/170 From jpereda at openjdk.org Tue Dec 5 12:10:19 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Dec 2023 12:10:19 GMT Subject: [jfx17u] RFR: 8299968: Second call to Stage.setScene() create sizing issue with uiScale > 1.0 Message-ID: Clean backport of 8299968: Second call to Stage.setScene() create sizing issue with uiScale > 1.0 Reviewed-by: kcr, arapte ------------- Commit messages: - 8299968: Second call to Stage.setScene() create sizing issue with uiScale > 1.0 Changes: https://git.openjdk.org/jfx17u/pull/171/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=171&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299968 Stats: 251 lines in 8 files changed: 247 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jfx17u/pull/171.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/171/head:pull/171 PR: https://git.openjdk.org/jfx17u/pull/171 From kevin.rushforth at oracle.com Tue Dec 5 16:25:39 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 5 Dec 2023 08:25:39 -0800 Subject: JavaFX and Panama In-Reply-To: References: Message-ID: Our current practice, as discussed in this thread [1], is to update the minimum to a JDK LTS release. I would be reluctant to adopt a non-LTS release as the minimum and based on the responses the last time we raised this question, I suspect there would be other voices even more reluctant. For the specific case of using Panama FFM or unnamed variable patterns, I don't see sufficient benefit to applications to justify it. These features would only be something used by JavaFX internals and wouldn't show up in any public API. I do support bumping the minimum to JDK 21 in JavaFX 23, and was already planning to propose doing so early in the JavaFX 23 release. -- Kevin [1] https://mail.openjdk.org/pipermail/openjfx-dev/2022-July/034874.html On 12/5/2023 12:28 AM, Nir Lisker wrote: > Hi all, > > Panama's 'foreign' API will be released?in JDK 22 [1][2]. It includes > 'foreign memory' API for managing off-heap java memory, and 'foreign > function' API for calling native functions. These replace some > sun.misc.unsafe operations and all JNI. > > We should start allowing developers to use the new APIs as they > greatly improve many aspects of the code (safer, simpler and possibly > more performant). I have used the foreign function API in other > projects since its incubation period (Java 18 or 19) and I can say > that it works well and causes much less headache than JNI, although I > didn't do a performance comparison in those cases. > > We should also think about replacing code with the new API. JavaFX > uses sun.miscs.Unsafe in MarlinFX, and JNI is used extensively. While > it's unreasonable?(and at this point undesirable?due to manpower > constraints) to replace all of JNI, there are places where this > approach should be looked at. The use of Unsafe also emits warnings, > which we are trying to avoid. > > I therefore propose that JavaFX 23 bump its Java requirement to 22, > maintaining the "N-1 guarantee". I think that this is a significant > enough addition that merits this version bump, and will also bring > with it all the previous features starting with Java 18, out of which > some useful ones are: > * Code Snippets [3] (18) > * Record Patterns [4] (21) > * Pattern Matching for switch [5] (21) > * Unnamed Variables & Patterns [6] (22) > > We can start using the new APIs once the jfx 22 branch is split from > the master. > > - Nir > > [1] https://openjdk.org/jeps/454 > [2] > https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/lang/foreign/package-summary.html > [3] https://openjdk.org/jeps/413 > [4] https://openjdk.org/jeps/440 > [5] https://openjdk.org/jeps/441 > [6] https://openjdk.org/jeps/456 > From jpereda at openjdk.org Tue Dec 5 18:45:11 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Dec 2023 18:45:11 GMT Subject: [jfx17u] RFR: 8299968: Second call to Stage.setScene() create sizing issue with uiScale > 1.0 [v2] In-Reply-To: References: Message-ID: > Clean backport of 8299968: Second call to Stage.setScene() create sizing issue with uiScale > 1.0 > > Reviewed-by: kcr, arapte Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Apply required changes from JDK-8206430 ------------- Changes: - all: https://git.openjdk.org/jfx17u/pull/171/files - new: https://git.openjdk.org/jfx17u/pull/171/files/4e9a6552..398e4731 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx17u&pr=171&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx17u&pr=171&range=00-01 Stats: 105 lines in 1 file changed: 102 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx17u/pull/171.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/171/head:pull/171 PR: https://git.openjdk.org/jfx17u/pull/171 From andy.goryachev at oracle.com Tue Dec 5 19:23:39 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 5 Dec 2023 19:23:39 +0000 Subject: Reflective discovery of styleable properties In-Reply-To: References: Message-ID: I like the idea. I wonder if it is possible to reduce the amount of boilerplate code? For example, a CssMetaData can have a setGetter(Function> getter) method which supplies the property reference? This way CssMetaData.isSettable(Node) and CssMetaData.getStyleableProperty(Node) can be implemented in the base class (there are more complicated cases, so perhaps setIsSettable(Predicate) would also be required). Example: CssMetaData.of("-fx-font", Font.getDefault(), (n) -> n.font) Just a thought. What do you think? -andy From: openjfx-dev on behalf of Michael Strau? Date: Sunday, December 3, 2023 at 22:02 To: openjfx-dev Subject: Reflective discovery of styleable properties Following up the discussion around the CssMetaData API, I'd like to chime in with yet another idea. To recap, here's Nir's summary of the current API [0]: "Let's look at what implementation is required from a user who wants to write their own styleable control: 1. Create styleable properties. 2. Create a list of these properties to be passed on. 3. Create a public static method that returns the concatenation of this list with the one of its parent. (This method happens to be poorly documented, as mstr said.) 4. Create a public non-static method that calls the static method in a forced-override pattern because otherwise you will be calling the wrong static method. (This method's docs seem to be just wrong because you don't always want to delegate to Node's list.)" I think this could reasonably be replaced with the following implementation requirements: 1. Create styleable properties. 2. That's it. Let's look at what we're actually trying to do: create a list of CSS-styleable property metadata of a class. But we can easily do that without all of the boilerplate code. When ?Node.getCssMetaData()` is invoked, all public methods of the class are reflectively enumerated, and metadata is retrieved from `Property` and `StyleableProperty` getters. This is a price that's only paid once for any particular class (i.e. not for every instance). The resulting metadata list is cached and reused for all instances of that particular class. As a further optimization, metadata lists are also cached and deduplicated for Control/Skin combinations (currently every Control instance has its own copy of the metadata list). Another benefit of this approach is that the CssMetaData can now be co-located with the property implementation, and not be kept around in other parts of the source code file. Here's how that looks like when a new "myValue" property is added to MyClass: StyleableDoubleProperty myValue = new SimpleStyleableDoubleProperty(this, "myValue") { static final CssMetaData METADATA = new CssMetaData( "-fx-my-value", SizeConverter.getInstance(), USE_COMPUTED_SIZE) { @Override public boolean isSettable(MyClass node) { return !node.myValue.isBound(); } @Override public StyleableProperty getStyleableProperty( MyClass node) { return node.myValue; } }; @Override public CssMetaData getCssMetaData() { return METADATA; } }; public final DoubleProperty myValueProperty() { return myValue; } It is not required to override the `getCssMetaData()` method, nor is it required to redeclare a new static `getClassCssMetaData()` method. It is also not required to manually keep the list of styleable properties in sync with the list of CSS metadata. I've prototyped this concept for the `Node`, `Region` and `Control` classes [1]. [0] https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044046.html [1] https://github.com/openjdk/jfx/pull/1299 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Dec 5 19:27:15 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 5 Dec 2023 19:27:15 +0000 Subject: eclipse warnings In-Reply-To: <7c147924-7624-ec3f-b0ce-cface7740800@gmail.com> References: <7c147924-7624-ec3f-b0ce-cface7740800@gmail.com> Message-ID: > I did many warning fixes, and there are PR's outstanding with warning fixes, but they're not getting reviewed. Are they still in Draft? https://github.com/openjdk/jfx/pulls?q=is%3Aopen+is%3Apr+label%3Arfr -andy From: openjfx-dev on behalf of John Hendrikx Date: Tuesday, December 5, 2023 at 03:16 To: openjfx-dev at openjdk.org Subject: Re: eclipse warnings IMHO, there is no capacity for this. I did many warning fixes, and there are PR's outstanding with warning fixes, but they're not getting reviewed. There are other PR's outstanding that are more valuable, but are not getting reviewed. I feel we need to fix that first before we can endulge in warning fixes. As for the potential null pointer access, it's often a false positive; static analyzers have a hard time determining if a loop is entered at least once (or an if in that loop) and so will warn that a local can maybe be null if it was initalized inside a loop. --John On 04/12/2023 17:34, Andy Goryachev wrote: Dear colleagues: Imported the openjfx project into another workspace with a more stringent error checking and discovered a few issues: 1. potential null pointer access: 295 2. unnecessary cast or instanceof: 190 3. redundant null check: 61 Do we want to clean these up? -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Tue Dec 5 20:42:43 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 5 Dec 2023 21:42:43 +0100 Subject: eclipse warnings In-Reply-To: <3fdea815-67bc-f1c9-abca-02a46a1b39fd@gmail.com> References: <3fdea815-67bc-f1c9-abca-02a46a1b39fd@gmail.com> Message-ID: Unfortunately, this doesn't work. The Java language doesn't allow a pattern to be the same type as the expression. On Tue, Dec 5, 2023 at 1:27?PM John Hendrikx wrote: > > When this runs on the FX thread it has to be safe, but it's not very nice. > > These days you can do these kind of null chain checks like this: > > if (getScene() instanceof Scene s && s.getWindow() instanceof > Window w && w.isShowing()) { > > } > > --John From john.hendrikx at gmail.com Tue Dec 5 22:17:35 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 5 Dec 2023 23:17:35 +0100 Subject: eclipse warnings In-Reply-To: References: <7c147924-7624-ec3f-b0ce-cface7740800@gmail.com> Message-ID: <68561561-03cd-ab1b-3d2e-936746431bde@gmail.com> This one for example: https://github.com/openjdk/jfx/pull/1095 It was auto closed, and at this point probably has many merge conflicts, which is why I let it go closed. --John On 05/12/2023 20:27, Andy Goryachev wrote: > > > I did many warning fixes, and there are PR's outstanding with warning > fixes, but they're not getting reviewed. > > Are they still in Draft? > > https://github.com/openjdk/jfx/pulls?q=is%3Aopen+is%3Apr+label%3Arfr > > -andy > > *From: *openjfx-dev on behalf of John > Hendrikx > *Date: *Tuesday, December 5, 2023 at 03:16 > *To: *openjfx-dev at openjdk.org > *Subject: *Re: eclipse warnings > > IMHO, there is no capacity for this. > > I did many warning fixes, and there are PR's outstanding with warning > fixes, but they're not getting reviewed. > > There are other PR's outstanding that are more valuable, but are not > getting reviewed. > > I feel we need to fix that first before we can endulge in warning fixes. > > As for the potential null pointer access, it's often a false positive; > static analyzers have a hard time determining if a loop is entered at > least once (or an if in that loop) and so will warn that a local can > maybe be null if it was initalized inside a loop. > > --John > > On 04/12/2023 17:34, Andy Goryachev wrote: > > Dear colleagues: > > Imported the openjfx project into another workspace with a more > stringent error checking and discovered a few issues: > > 1. potential null pointer access: 295 > 2. unnecessary cast or instanceof: 190 > 3. redundant null check: 61 > > Do we want to clean these up? > > -andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Dec 5 22:45:36 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 5 Dec 2023 22:45:36 +0000 Subject: [External] : Re: eclipse warnings In-Reply-To: <68561561-03cd-ab1b-3d2e-936746431bde@gmail.com> References: <7c147924-7624-ec3f-b0ce-cface7740800@gmail.com> <68561561-03cd-ab1b-3d2e-936746431bde@gmail.com> Message-ID: Yeah, that one. Probably for the better - very little probability of uncovering any bugs, and too high of a probability of introducing a regression. Same with "unnecessary cast or instanceof" and "redundant null check". "potential null pointer access" - there is probably some non-zero value in having the warning, but very few people would welcom @SuppressWarning where it isn't an issue. You are right though - there are more important issues to be resolved - 3,876 to be exact, see https://bugs.openjdk.org/issues/?jql=component%20in%20(javafx)%20and%20status%20in%20(open%2C%20new%2C%20%22In%20Progress%22)%20and%20labels%20not%20in%20(okToLeaveInJI) -andy From: John Hendrikx Date: Tuesday, December 5, 2023 at 14:17 To: Andy Goryachev , openjfx-dev at openjdk.org Subject: [External] : Re: eclipse warnings This one for example: https://github.com/openjdk/jfx/pull/1095 It was auto closed, and at this point probably has many merge conflicts, which is why I let it go closed. --John On 05/12/2023 20:27, Andy Goryachev wrote: > I did many warning fixes, and there are PR's outstanding with warning fixes, but they're not getting reviewed. Are they still in Draft? https://github.com/openjdk/jfx/pulls?q=is%3Aopen+is%3Apr+label%3Arfr -andy From: openjfx-dev on behalf of John Hendrikx Date: Tuesday, December 5, 2023 at 03:16 To: openjfx-dev at openjdk.org Subject: Re: eclipse warnings IMHO, there is no capacity for this. I did many warning fixes, and there are PR's outstanding with warning fixes, but they're not getting reviewed. There are other PR's outstanding that are more valuable, but are not getting reviewed. I feel we need to fix that first before we can endulge in warning fixes. As for the potential null pointer access, it's often a false positive; static analyzers have a hard time determining if a loop is entered at least once (or an if in that loop) and so will warn that a local can maybe be null if it was initalized inside a loop. --John On 04/12/2023 17:34, Andy Goryachev wrote: Dear colleagues: Imported the openjfx project into another workspace with a more stringent error checking and discovered a few issues: 1. potential null pointer access: 295 2. unnecessary cast or instanceof: 190 3. redundant null check: 61 Do we want to clean these up? -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From swpalmer at gmail.com Tue Dec 5 23:03:19 2023 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 5 Dec 2023 18:03:19 -0500 Subject: eclipse warnings In-Reply-To: References: Message-ID: <1F7B03D8-21D2-4EB1-846A-84CA2205DB1E@gmail.com> I was about to say the same. I wish it did, and applied the rule that null never matches. You could probably trick it with an ugly cast though. ((Object)getScene()) instanceof Scene s Maybe? Scott > On Dec 5, 2023, at 3:43?PM, Michael Strau? wrote: > > ?Unfortunately, this doesn't work. The Java language doesn't allow a > pattern to be the same type as the expression. > > >> On Tue, Dec 5, 2023 at 1:27?PM John Hendrikx wrote: >> >> When this runs on the FX thread it has to be safe, but it's not very nice. >> >> These days you can do these kind of null chain checks like this: >> >> if (getScene() instanceof Scene s && s.getWindow() instanceof >> Window w && w.isShowing()) { >> >> } >> >> --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Tue Dec 5 23:47:46 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 5 Dec 2023 23:47:46 GMT Subject: RFR: 8282290: TextField Cursor Position one off [v3] In-Reply-To: <3O0CgH2CRPXmxTsFHviBRSFqbKn2s6H_7LLSKHtExSw=.1534fb3e-1648-4d83-930f-e3010c5bed62@github.com> References: <3O0CgH2CRPXmxTsFHviBRSFqbKn2s6H_7LLSKHtExSw=.1534fb3e-1648-4d83-930f-e3010c5bed62@github.com> Message-ID: On Fri, 1 Dec 2023 14:28:43 GMT, Karthik P K wrote: >> The change listener on caretPositionProperty() was not getting invoked on replacing the content with same text as there was no change in caret position. Since the textProperty invalidation sets the forward bias to true by default, incorrect caret position was calculated when the same text was replaced after clicking on the trailing edge of last character or empty space in the TextField. >> >> Since caretShapeProperty invalidation listener gets invoked without changing the caret position, updating the caretBiasProperty on this listener solves the issue. >> >> Since the caret position value will be same when the caret is present after the last character or before the last character, it can not be validated using unit test. >> The fix can be validated using MonkeyTester. >> Steps to select TextField option in Monkey Tester. >> >> - Open the MonkeyTester app and select TextField from the left option pane. >> - Select Short from Text selection option and click on the TextField to bring it into focus. >> - Select all using cmd(ctrl) + a and copy using cmd(ctrl) + c >> - Click on empty space in the TextField after the present content. >> - Select all again using the keyboard shortcut and paste using cmd(ctrl) + v >> - The caret should be displayed after the last character. Without the fix caret gets displayed before the last character. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Looks good. ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1287#pullrequestreview-1766307241 From kcr at openjdk.org Tue Dec 5 23:51:20 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Dec 2023 23:51:20 GMT Subject: RFR: 8301302: Platform preferences API [v39] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <4b5ntMAevRGKg7QTxKxT-v8CV7ddeWMtgTA8_jT0aGQ=.7a0725f1-637e-41eb-a7ca-537bd740f9e1@github.com> On Mon, 4 Dec 2023 23:55:33 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > check return value of JNI functions I've finished reviewing the native code. I left a few more comments and questions, mainly in RoActivationSupport. modules/javafx.graphics/src/main/native-glass/mac/GlassMacros.h line 178: > 176: > 177: #define GLASS_CHECK_NONNULL_EXCEPTIONALLY_RETURN(ENV, EXPR) \ > 178: GLASS_CHECK_EXCEPTION(ENV); \ Should this call `GLASS_CHECK_EXCEPTIONALLY_RETURN` instead? It doesn't matter for the current places where it is used, but it might be more consistent. modules/javafx.graphics/src/main/native-glass/win/RoActivationSupport.cpp line 159: > 157: memset(wstr, 0, wstr_len * sizeof(WCHAR)); > 158: MultiByteToWideChar(CP_UTF8, 0, str, -1, wstr, wstr_len); > 159: WindowsCreateString(wstr, wstr_len - 1, &hstr_); This could use some error checking. At a minimum, `wstr` should be checked for null and skip the rest if it is. I think you also should check `wstr_len == 0`, since it is will return 0 on error. You might also consider whether you need to check the return value of `WindowsCreateString`. You would need to make sure `hstr_ = nullptr` if there are any errors. modules/javafx.graphics/src/main/native-glass/win/RoActivationSupport.cpp line 165: > 163: hstring::~hstring() > 164: { > 165: WindowsDeleteString(hstr_); After adding the check for a failure to allocate the string, a null check is needed here (unless `WindowsDeleteString` specifies that it does nothing if the string is null). modules/javafx.graphics/src/main/native-glass/win/RoActivationSupport.cpp line 182: > 180: size_t len = strlen(message); > 181: char* msg = new char[len + 1]; > 182: strcpy_s(msg, len + 1, message); You should check for null before copying. modules/javafx.graphics/src/main/native-glass/win/RoActivationSupport.cpp line 199: > 197: char* result = new char[message_length + error_length]; > 198: WideCharToMultiByte(CP_ACP, 0, error, -1, result + message_length, error_length, NULL, FALSE); > 199: memcpy_s(result, message_length, message, message_length); Same comment about error checking as in `hstring`. modules/javafx.graphics/src/main/native-glass/win/RoActivationSupport.cpp line 208: > 206: RoException::~RoException() > 207: { > 208: delete[] message_; Check `message_` for null (meaning you will need to initialize it to null in case of error). modules/javafx.graphics/src/main/native-glass/win/RoActivationSupport.cpp line 213: > 211: RoException& RoException::operator=(RoException source) > 212: { > 213: std::swap(*this, source); Did you mean to do the swap here? ------------- PR Review: https://git.openjdk.org/jfx/pull/1014#pullrequestreview-1763528794 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1416402043 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1416377863 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1416379302 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1416380431 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1416380902 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1416394171 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1416396832 From kcr at openjdk.org Tue Dec 5 23:51:20 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Dec 2023 23:51:20 GMT Subject: RFR: 8301302: Platform preferences API [v37] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Sat, 2 Dec 2023 01:43:52 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > check for pending exceptions in Windows PlatformSupport modules/javafx.graphics/src/main/native-glass/mac/GlassMacros.h line 165: > 163: > 164: // assert there is no outstanding java exception pending, return otherwise > 165: #define GLASS_CHECK_EXCEPTIONALLY_RETURN(ENV) \ Minor: `GLASS_CHECK_EXCEPTION_RETURN` might be a more consistent name (but please leave it as is if you prefer). modules/javafx.graphics/src/main/native-glass/win/PlatformSupport.cpp line 235: > 233: jobject prefValue = value ? > 234: env->GetStaticObjectField(javaClasses.Boolean, javaIDs.Boolean.trueID) : > 235: env->GetStaticObjectField(javaClasses.Boolean, javaIDs.Boolean.falseID); Minor: do you think it is worth caching `Boolean.TRUE` and `Boolean.FALSE` in static `const` variables? It likely won't matter much. modules/javafx.graphics/src/test/java/test/com/sun/javafx/application/preferences/ChangedValueTest.java line 2: > 1: /* > 2: * Copyright (c) 2023 Oracle and/or its affiliates. All rights reserved. Missing comma after `2023` modules/javafx.graphics/src/test/java/test/com/sun/javafx/application/preferences/PlatformPreferencesTest.java line 2: > 1: /* > 2: * Copyright (c) 2023 Oracle and/or its affiliates. All rights reserved. Missing comma after `2023` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1414563364 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1414568701 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1414583048 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1414583300 From john.hendrikx at gmail.com Wed Dec 6 00:51:17 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 6 Dec 2023 01:51:17 +0100 Subject: [External] : Re: eclipse warnings In-Reply-To: References: <7c147924-7624-ec3f-b0ce-cface7740800@gmail.com> <68561561-03cd-ab1b-3d2e-936746431bde@gmail.com> Message-ID: I think the danger of regressions from fixing such warnings is incredibly low.? Fixing raw types finds potential casting problems, ie: ????? List list = List.of("Hi"); ????? Integer x = (Integer) list.get(0);? // Runtime CCE With the type for List specified, it would be a compile error instead. It was deemed so important to the Java platform that it introduced generics in 1.5, but kept raw types as a backwards compatiblity mechanism (not as a "convenience" mechanism to avoid having to specify the generic parameters -- all code after 1.5 should specify generics, and never use raw types). The PR uncovered a few incorrectly specified generics, although it was unlikely there were any resulting bugs, as the incorrect generics were in the CSS subsystem which ignores them all everywhere anyway. The generics in the CSS subsystem were used without thinking if they were useful or needed, with ParsedValue being the main offender.? It offers zero benefits to have this one generic as you're always dealing with parsed input that won't have a compile time type known in advance (all type checking is done in the parser, manually).? Unfortunately, the class is public API, but causes raw type warnings throughout the whole CSS subsystem.? If there had been an attempt to fill in reasonable generic types for this class everywhere, one would have realized the generic parameters on this type was not very useful, and could have been dropped from the definition (instead of dropping it on every use site using a raw type -- if you find yourself doing that a lot, the problem might be in the generic definition itself...). There were a few other classes like that which were not public API that had problematic generic parameters (`PartitionKey` for example, as it added nothing). --John On 05/12/2023 23:45, Andy Goryachev wrote: > > Yeah, that one.? Probably for the better - very little probability of > uncovering any bugs, and too high of a probability of introducing a > regression. > > Same with "unnecessary cast or instanceof" and "redundant null > check".? "potential null pointer access" - there is probably some > non-zero value in having the warning, but very few people would welcom > @SuppressWarning where it isn't an issue. > > You are right though - there are more important issues to be resolved > - 3,876 to be exact, see > > https://bugs.openjdk.org/issues/?jql=component%20in%20(javafx)%20and%20status%20in%20(open%2C%20new%2C%20%22In%20Progress%22)%20and%20labels%20not%20in%20(okToLeaveInJI) > > -andy > > *From: *John Hendrikx > *Date: *Tuesday, December 5, 2023 at 14:17 > *To: *Andy Goryachev , > openjfx-dev at openjdk.org > *Subject: *[External] : Re: eclipse warnings > > This one for example: https://github.com/openjdk/jfx/pull/1095 > > > It was auto closed, and at this point probably has many merge > conflicts, which is why I let it go closed. > > --John > > On 05/12/2023 20:27, Andy Goryachev wrote: > > > I did many warning fixes, and there are PR's outstanding with warning > fixes, but they're not getting reviewed. > > Are they still in Draft? > > https://github.com/openjdk/jfx/pulls?q=is%3Aopen+is%3Apr+label%3Arfr > > > -andy > > *From: *openjfx-dev > on behalf of John Hendrikx > > *Date: *Tuesday, December 5, 2023 at 03:16 > *To: *openjfx-dev at openjdk.org > > *Subject: *Re: eclipse warnings > > IMHO, there is no capacity for this. > > I did many warning fixes, and there are PR's outstanding with warning > fixes, but they're not getting reviewed. > > There are other PR's outstanding that are more valuable, but are not > getting reviewed. > > I feel we need to fix that first before we can endulge in warning fixes. > > As for the potential null pointer access, it's often a false positive; > static analyzers have a hard time determining if a loop is entered at > least once (or an if in that loop) and so will warn that a local can > maybe be null if it was initalized inside a loop. > > --John > > On 04/12/2023 17:34, Andy Goryachev wrote: > > > Dear colleagues: > > Imported the openjfx project into another workspace with a more > stringent error checking and discovered a few issues: > > 1. potential null pointer access: 295 > 2. unnecessary cast or instanceof: 190 > 3. redundant null check: 61 > > Do we want to clean these up? > > -andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Wed Dec 6 00:52:32 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Dec 2023 00:52:32 GMT Subject: RFR: 8301302: Platform preferences API [v40] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - null checking - rename GLASS_CHECK_EXCEPTIONALLY_RETURN ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/0dff7a49..db393fca Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=39 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=38-39 Stats: 44 lines in 5 files changed: 20 ins; 2 del; 22 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Wed Dec 6 01:02:19 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Dec 2023 01:02:19 GMT Subject: RFR: 8301302: Platform preferences API [v37] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Mon, 4 Dec 2023 22:05:53 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> check for pending exceptions in Windows PlatformSupport > > modules/javafx.graphics/src/main/native-glass/mac/GlassMacros.h line 165: > >> 163: >> 164: // assert there is no outstanding java exception pending, return otherwise >> 165: #define GLASS_CHECK_EXCEPTIONALLY_RETURN(ENV) \ > > Minor: `GLASS_CHECK_EXCEPTION_RETURN` might be a more consistent name (but please leave it as is if you prefer). I changed the name of this macro, as well as that of `GLASS_CHECK_NONNULL_EXCEPTIONALLY_RETURN`. > modules/javafx.graphics/src/main/native-glass/win/PlatformSupport.cpp line 235: > >> 233: jobject prefValue = value ? >> 234: env->GetStaticObjectField(javaClasses.Boolean, javaIDs.Boolean.trueID) : >> 235: env->GetStaticObjectField(javaClasses.Boolean, javaIDs.Boolean.falseID); > > Minor: do you think it is worth caching `Boolean.TRUE` and `Boolean.FALSE` in static `const` variables? It likely won't matter much. I don't think it matters one way or the other. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1416483975 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1416484821 From mstrauss at openjdk.org Wed Dec 6 01:02:20 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Dec 2023 01:02:20 GMT Subject: RFR: 8301302: Platform preferences API [v39] In-Reply-To: <4b5ntMAevRGKg7QTxKxT-v8CV7ddeWMtgTA8_jT0aGQ=.7a0725f1-637e-41eb-a7ca-537bd740f9e1@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <4b5ntMAevRGKg7QTxKxT-v8CV7ddeWMtgTA8_jT0aGQ=.7a0725f1-637e-41eb-a7ca-537bd740f9e1@github.com> Message-ID: On Tue, 5 Dec 2023 23:32:41 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> check return value of JNI functions > > modules/javafx.graphics/src/main/native-glass/mac/GlassMacros.h line 178: > >> 176: >> 177: #define GLASS_CHECK_NONNULL_EXCEPTIONALLY_RETURN(ENV, EXPR) \ >> 178: GLASS_CHECK_EXCEPTION(ENV); \ > > Should this call `GLASS_CHECK_EXCEPTIONALLY_RETURN` instead? It doesn't matter for the current places where it is used, but it might be more consistent. Yes. > modules/javafx.graphics/src/main/native-glass/win/RoActivationSupport.cpp line 159: > >> 157: memset(wstr, 0, wstr_len * sizeof(WCHAR)); >> 158: MultiByteToWideChar(CP_UTF8, 0, str, -1, wstr, wstr_len); >> 159: WindowsCreateString(wstr, wstr_len - 1, &hstr_); > > This could use some error checking. At a minimum, `wstr` should be checked for null and skip the rest if it is. I think you also should check `wstr_len == 0`, since it is will return 0 on error. You might also consider whether you need to check the return value of `WindowsCreateString`. You would need to make sure `hstr_ = nullptr` if there are any errors. I added the checks, but not for `WindowsCreateString`, since it is specified to set `hstr_` to null in case of failure. > modules/javafx.graphics/src/main/native-glass/win/RoActivationSupport.cpp line 165: > >> 163: hstring::~hstring() >> 164: { >> 165: WindowsDeleteString(hstr_); > > After adding the check for a failure to allocate the string, a null check is needed here (unless `WindowsDeleteString` specifies that it does nothing if the string is null). `WindowsDeleteString` does nothing when null is passed into it, but I added a null check anyway so people don't stumble upon it and wonder. > modules/javafx.graphics/src/main/native-glass/win/RoActivationSupport.cpp line 182: > >> 180: size_t len = strlen(message); >> 181: char* msg = new char[len + 1]; >> 182: strcpy_s(msg, len + 1, message); > > You should check for null before copying. Done. > modules/javafx.graphics/src/main/native-glass/win/RoActivationSupport.cpp line 199: > >> 197: char* result = new char[message_length + error_length]; >> 198: WideCharToMultiByte(CP_ACP, 0, error, -1, result + message_length, error_length, NULL, FALSE); >> 199: memcpy_s(result, message_length, message, message_length); > > Same comment about error checking as in `hstring`. Done. > modules/javafx.graphics/src/main/native-glass/win/RoActivationSupport.cpp line 208: > >> 206: RoException::~RoException() >> 207: { >> 208: delete[] message_; > > Check `message_` for null (meaning you will need to initialize it to null in case of error). I added a null check, and also initialize the field to null in the constructor. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1416495255 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1416486073 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1416494229 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1416494466 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1416494701 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1416495125 From mstrauss at openjdk.org Wed Dec 6 01:06:19 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Dec 2023 01:06:19 GMT Subject: RFR: 8301302: Platform preferences API [v39] In-Reply-To: <4b5ntMAevRGKg7QTxKxT-v8CV7ddeWMtgTA8_jT0aGQ=.7a0725f1-637e-41eb-a7ca-537bd740f9e1@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <4b5ntMAevRGKg7QTxKxT-v8CV7ddeWMtgTA8_jT0aGQ=.7a0725f1-637e-41eb-a7ca-537bd740f9e1@github.com> Message-ID: On Tue, 5 Dec 2023 23:26:11 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> check return value of JNI functions > > modules/javafx.graphics/src/main/native-glass/win/RoActivationSupport.cpp line 213: > >> 211: RoException& RoException::operator=(RoException source) >> 212: { >> 213: std::swap(*this, source); > > Did you mean to do the swap here? Yes. This is the copy-and-swap idiom, where the copy is made by using a pass-by-value parameter. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1416497565 From kpk at openjdk.org Wed Dec 6 03:54:49 2023 From: kpk at openjdk.org (Karthik P K) Date: Wed, 6 Dec 2023 03:54:49 GMT Subject: Integrated: 8282290: TextField Cursor Position one off In-Reply-To: References: Message-ID: <6_gucVSwOU6db2i31Wb8foEoYI8aHUpZYCKf_EjMTYE=.530398e4-217e-4fa7-babd-8f4cabc6cb4b@github.com> On Tue, 14 Nov 2023 10:24:20 GMT, Karthik P K wrote: > The change listener on caretPositionProperty() was not getting invoked on replacing the content with same text as there was no change in caret position. Since the textProperty invalidation sets the forward bias to true by default, incorrect caret position was calculated when the same text was replaced after clicking on the trailing edge of last character or empty space in the TextField. > > Since caretShapeProperty invalidation listener gets invoked without changing the caret position, updating the caretBiasProperty on this listener solves the issue. > > Since the caret position value will be same when the caret is present after the last character or before the last character, it can not be validated using unit test. > The fix can be validated using MonkeyTester. > Steps to select TextField option in Monkey Tester. > > - Open the MonkeyTester app and select TextField from the left option pane. > - Select Short from Text selection option and click on the TextField to bring it into focus. > - Select all using cmd(ctrl) + a and copy using cmd(ctrl) + c > - Click on empty space in the TextField after the present content. > - Select all again using the keyboard shortcut and paste using cmd(ctrl) + v > - The caret should be displayed after the last character. Without the fix caret gets displayed before the last character. This pull request has now been integrated. Changeset: 2108ecf9 Author: Karthik P K URL: https://git.openjdk.org/jfx/commit/2108ecf9d7c8c459964a9e8b5e37485b3507b028 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod 8282290: TextField Cursor Position one off 8248914: Javafx TextField positions the cursor incorrectly after pressing DEL key Reviewed-by: angorya, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1287 From nlisker at gmail.com Wed Dec 6 10:37:22 2023 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 6 Dec 2023 12:37:22 +0200 Subject: Reflective discovery of styleable properties In-Reply-To: References: Message-ID: I thought about the option of reflection, but I opted to propose annotations instead. The following is my reasoning. Firstly, reflection is very magic-y. The author of the class has no indication of what side effects happen due to the code they write, the output (css handling in this case) comes out of nowhere from their perspective. As with other reflection cases, it is a "pull" rather than "push" approach - you don't write what should happen, you let someone else decide that. For writers of skin/control classes, this means that they need to know exactly what constitutes a hook for the reflection mechanism, or face surprises. There is no compile time check that tells you whether you have declared your styleable property properly or not (without an external ad-hoc checker). We do this somewhat with properties - any method of the form "...property()" gets special treatment, but this is for the docs. I don't think we have code that depends on this other than in tests. Secondly, the proposed mechanism depends on the runtime type, not the declared type. As a user, I see no indication in the API whether a property is styleable or not. This is also (what I would consider) a problem with the current state. When I thought about using reflection to solve this, I at least thought to specify the declared type of the property as styleable, like StyleableBooleanProperty instead of BooleanProperty (restricting the returned type is backwards compatible). A downside of this is that it gives access to the methods of StyleableProperty, which are not useful for the user, I think, but maybe someone has a use for them. Thirdly, maybe I want to declare a styleable property not to be used automatically. I can't think off the top of my head when I would want to do that, but I'm also not a heavy css user. Are we sure that just initializing a property with a styleable runtime type should *always* be caught by this process? To compare, annotations have the following benefits: Firstly, they are declarative, which means no surprises for the class author (WYSIWYG). This also allows more flexibility/control over which properties get special treatment via an opt-in mechanism. Secondly, They can also be displayed in the JavaDocs (via @Documented) with their assigned values. For example, the padding property of Region can be annotated with @Styleable(property="-fx-padding"), informing the user both that this value can be set by css, and how to do it. Interestingly, the annotation doesn't need to be public API to be displayed, so we are not bound by contracts. In terms of similarities: In both the reflection and the annotation proposals, the steps are: 1. Create styleable properties. 2. That's it. It's just that step 1 also adds an annotation to the creation of the property (which was/is a 2-step process anyway, declaring the property and its css metadata). Annotations also require a processor to read the data from their values and target (the field/method). This is a bit of work, but Michael's CssMetaDataCache class is basically that - read the data from the class (via reflection or annotations) and store it in a map. The logic should be the same, just the method to obtain the data is different. Both, as a result, have the benefits of handling control/skin combinations (what I mentioned in the point "Usable both in controls and in skins (or other classes)"). The benefit of co-locating the property and its css metadata in the class itself also remains. To summarize, both approaches eliminate all the clutter of writing styleable properties (John, will you like to create styleable properties now? [1] :) ), both apply the flexibility of caching per class, both allow better structuring of the class, but they read the properties differently and have a different level of declarativness. [1] https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044010.html On Tue, Dec 5, 2023 at 11:21?PM Andy Goryachev wrote: > I like the idea. > > > > I wonder if it is possible to reduce the amount of boilerplate code? For > example, a CssMetaData can have a > > > > setGetter(Function> getter) > > > > method which supplies the property reference? This way > CssMetaData.isSettable(Node) and CssMetaData.getStyleableProperty(Node) can > be implemented in the base class (there are more complicated cases, so > perhaps setIsSettable(Predicate) would also be required). > > > > Example: > > > > CssMetaData.of("-fx-font", Font.getDefault(), (n) -> > n.font) > > > > Just a thought. What do you think? > > > > -andy > > > > > > *From: *openjfx-dev on behalf of Michael > Strau? > *Date: *Sunday, December 3, 2023 at 22:02 > *To: *openjfx-dev > *Subject: *Reflective discovery of styleable properties > > Following up the discussion around the CssMetaData API, I'd like to > chime in with yet another idea. To recap, here's Nir's summary of the > current API [0]: > > "Let's look at what implementation is required from a user who wants > to write their own styleable control: > 1. Create styleable properties. > 2. Create a list of these properties to be passed on. > 3. Create a public static method that returns the concatenation of > this list with the one of its parent. (This method happens to be > poorly documented, as mstr said.) > 4. Create a public non-static method that calls the static method in a > forced-override pattern because otherwise you will be calling the > wrong static method. (This method's docs seem to be just wrong because > you don't always want to delegate to Node's list.)" > > > I think this could reasonably be replaced with the following > implementation requirements: > 1. Create styleable properties. > 2. That's it. > > Let's look at what we're actually trying to do: create a list of > CSS-styleable property metadata of a class. But we can easily do that > without all of the boilerplate code. > > When ?Node.getCssMetaData()` is invoked, all public methods of the > class are reflectively enumerated, and metadata is retrieved from > `Property` and `StyleableProperty` getters. This is a price that's > only paid once for any particular class (i.e. not for every instance). > The resulting metadata list is cached and reused for all instances of > that particular class. > > As a further optimization, metadata lists are also cached and > deduplicated for Control/Skin combinations (currently every Control > instance has its own copy of the metadata list). > > Another benefit of this approach is that the CssMetaData can now be > co-located with the property implementation, and not be kept around in > other parts of the source code file. Here's how that looks like when a > new "myValue" property is added to MyClass: > > StyleableDoubleProperty myValue = > new SimpleStyleableDoubleProperty(this, "myValue") { > > static final CssMetaData METADATA = > new CssMetaData( > "-fx-my-value", > SizeConverter.getInstance(), > USE_COMPUTED_SIZE) { > @Override > public boolean isSettable(MyClass node) { > return !node.myValue.isBound(); > } > > @Override > public StyleableProperty getStyleableProperty( > MyClass node) { > return node.myValue; > } > }; > > @Override > public CssMetaData getCssMetaData() { > return METADATA; > } > }; > > public final DoubleProperty myValueProperty() { > return myValue; > } > > It is not required to override the `getCssMetaData()` method, nor is > it required to redeclare a new static `getClassCssMetaData()` method. > It is also not required to manually keep the list of styleable > properties in sync with the list of CSS metadata. > > I've prototyped this concept for the `Node`, `Region` and `Control` > classes [1]. > > [0] > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044046.html > [1] https://github.com/openjdk/jfx/pull/1299 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Wed Dec 6 10:45:43 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 6 Dec 2023 11:45:43 +0100 Subject: eclipse warnings In-Reply-To: <1F7B03D8-21D2-4EB1-846A-84CA2205DB1E@gmail.com> References: <1F7B03D8-21D2-4EB1-846A-84CA2205DB1E@gmail.com> Message-ID: Ah, that's a shame, it would have been useful ;-) --John On 06/12/2023 00:03, Scott Palmer wrote: > I was about to say the same. I wish it did, and applied the rule that > null never matches. > > You could probably trick it with an ugly cast though. > > ((Object)getScene()) instanceof Scene s > Maybe? > > Scott > >> On Dec 5, 2023, at 3:43?PM, Michael Strau? >> wrote: >> >> ?Unfortunately, this doesn't work. The Java language doesn't allow a >> pattern to be the same type as the expression. >> >> >> On Tue, Dec 5, 2023 at 1:27?PM John Hendrikx >> wrote: >>> >>> When this runs on the FX thread it has to be safe, but it's not very >>> nice. >>> >>> These days you can do these kind of null chain checks like this: >>> >>> ??????if (getScene() instanceof Scene s && s.getWindow() instanceof >>> Window w && w.isShowing()) { >>> >>> ??????} >>> >>> --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Wed Dec 6 12:16:41 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 6 Dec 2023 13:16:41 +0100 Subject: Reflective discovery of styleable properties In-Reply-To: References: Message-ID: <3cfd7806-45c1-1d52-2f78-c0ab1c5076cf@gmail.com> I also like this route, perhaps slightly more, depending on how far this can be taken: Disclaimer: I dislike the CSSMetaData and special property subclass a lot -- it's a major concession to make properties work with the CSS system that brings a lot of boilerplate that is mostly unnecessary. If you go the route of an annotation, we could offer to do everything via the annotation so a regular property can be converted to styleable by annotating it.? The property would then have to specify the name ("-fx-label-padding") and the default value (which can be a string that is parseable via the existing CSS parser). In other words: @Styleable(name = "-fx-label-padding", defaultValue = "(0, 0, 0, 0)") publicfinalReadOnlyObjectProperty labelPaddingProperty() { ... } The rest the scanner can figure out (it could even figure out a default name). The `isSettable` method is always the same boilerplate (and if not, you can use the old way).? The required converter can be derived from the generic type (Insets -> InsetsConverter), or specified (converter = InsetsConverter.class). To convert a regular property into a styleable does require somewhat more magic (the CSS system would have to wrap it, or otherwise track them) but that's all hidden. It gets rid of the StyleableProperty uglyness and the need for users to create those, and puts the "extra" CSSMetaData information a styleable property needs firmly where it belongs (in an annotation). --John On 06/12/2023 11:37, Nir Lisker wrote: > I thought about the option of reflection, but I opted?to propose > annotations instead. The following is my reasoning. > > Firstly, reflection is very magic-y. The author of the class has no > indication of what side effects happen due to the code they write, the > output (css handling in this case) comes out of nowhere from their > perspective. As with other reflection cases, it is a "pull" rather > than "push" approach - you don't write what should happen, you let > someone else decide?that. For writers of skin/control classes, this > means that they need to know exactly what constitutes?a hook for the > reflection mechanism, or face surprises. There is no compile time > check that tells you whether you have declared your styleable property > properly or not (without an external ad-hoc checker). > We do this somewhat with properties - any method of the form > "...property()" gets special treatment, but this is for the docs. I > don't think we have code that depends on this other than in tests. > > Secondly, the proposed mechanism depends on the runtime type, not the > declared type. As a user, I see no indication in the API whether a > property is styleable or not. This is also (what I would consider) a > problem with the current state. When I thought about using reflection > to solve this, I at least thought to specify the declared type of the > property as styleable, like StyleableBooleanProperty instead of > BooleanProperty (restricting the returned type is backwards > compatible). A downside of this is that it gives access to the methods > of StyleableProperty, which are not useful for the user, I think, but > maybe someone has a use for them. > > Thirdly, maybe I want to declare a styleable property?not to be used > automatically. I can't think off the top of my head when I would want > to do that, but I'm also not a heavy css user. Are we sure that just > initializing a property with a styleable runtime type should *always* > be caught by this process? > > To compare, annotations have the following benefits: > > Firstly, they are declarative, which means no surprises for the class > author (WYSIWYG). This also allows more flexibility/control over which > properties get special treatment via an opt-in mechanism. > > Secondly, They can also be displayed in the JavaDocs (via?@Documented) > with their assigned values. For example, the padding property of > Region can be annotated with?@Styleable(property="-fx-padding"), > informing the user both that this value can be set by css, and how to > do it. Interestingly, the annotation doesn't need to be public API to > be displayed, so we are not bound by contracts. > > In terms of similarities: > > In both the reflection and the annotation proposals, the steps are: > 1. Create styleable properties. > 2. That's it. > It's just that step 1 also adds an annotation to the creation of the > property (which was/is a 2-step process anyway, declaring the property > and its?css metadata). > > Annotations also require a processor to read the data from their > values and target (the field/method). This is a bit of work, but > Michael's?CssMetaDataCache class is basically that - read the data > from the class (via reflection or annotations) and store it in a map. > The logic should be the same, just the method to obtain the data is > different. Both, as a result, have the benefits of handling > control/skin combinations (what I mentioned in the point "Usable both > in controls and in skins (or other classes)"). > > The benefit of co-locating the property and its css metadata in the > class itself also remains. > > > To summarize, both approaches eliminate all the clutter of writing > styleable properties (John, will you like to create styleable > properties now? [1] :) ), both apply the flexibility of caching per > class, both allow better structuring of the class, but they read the > properties differently and have a different level of declarativness. > > [1] > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044010.html > > > On Tue, Dec 5, 2023 at 11:21?PM Andy Goryachev > wrote: > > I like the idea. > > I wonder if it is possible to reduce the amount of boilerplate > code?? For example, a CssMetaData can have a > > setGetter(Function> getter) > > method which supplies the property reference?? This way > CssMetaData.isSettable(Node) and > CssMetaData.getStyleableProperty(Node) can be implemented in the > base class (there are more complicated cases, so perhaps > setIsSettable(Predicate) would also be required). > > Example: > > CssMetaData.of("-fx-font", Font.getDefault(), > (n) -> n.font) > > Just a thought.? What do you think? > > -andy > > *From: *openjfx-dev on behalf of > Michael Strau? > *Date: *Sunday, December 3, 2023 at 22:02 > *To: *openjfx-dev > *Subject: *Reflective discovery of styleable properties > > Following up the discussion around the CssMetaData API, I'd like to > chime in with yet another idea. To recap, here's Nir's summary of the > current API [0]: > > "Let's look at what implementation is required from a user who wants > to write their own styleable control: > 1. Create styleable properties. > 2. Create a list of these properties to be passed on. > 3. Create a public static method that returns the concatenation of > this list with the one of its parent. (This method happens to be > poorly documented, as mstr said.) > 4. Create a public non-static method that calls the static method in a > forced-override pattern because otherwise you will be calling the > wrong static method. (This method's docs seem to be just wrong because > you don't always want to delegate to Node's list.)" > > > I think this could reasonably be replaced with the following > implementation requirements: > 1. Create styleable properties. > 2. That's it. > > Let's look at what we're actually trying to do: create a list of > CSS-styleable property metadata of a class. But we can easily do that > without all of the boilerplate code. > > When ?Node.getCssMetaData()` is invoked, all public methods of the > class are reflectively enumerated, and metadata is retrieved from > `Property` and `StyleableProperty` getters. This is a price that's > only paid once for any particular class (i.e. not for every instance). > The resulting metadata list is cached and reused for all instances of > that particular class. > > As a further optimization, metadata lists are also cached and > deduplicated for Control/Skin combinations (currently every Control > instance has its own copy of the metadata list). > > Another benefit of this approach is that the CssMetaData can now be > co-located with the property implementation, and not be kept around in > other parts of the source code file. Here's how that looks like when a > new "myValue" property is added to MyClass: > > ??? StyleableDoubleProperty myValue = > ??????????? new SimpleStyleableDoubleProperty(this, "myValue") { > > ??????? static final CssMetaData METADATA = > ??????????? new CssMetaData( > ??????????????? "-fx-my-value", > ??????????????? SizeConverter.getInstance(), > ??????????????? USE_COMPUTED_SIZE) { > ??????????? @Override > ??????????? public boolean isSettable(MyClass node) { > ??????????????? return !node.myValue.isBound(); > ??????????? } > > ??????????? @Override > ??????????? public StyleableProperty getStyleableProperty( > ??????????????????? MyClass node) { > ??????????????? return node.myValue; > ??????????? } > ??????? }; > > ??????? @Override > ??????? public CssMetaData getCssMetaData() { > ??????????? return METADATA; > ??????? } > ??? }; > > ??? public final DoubleProperty myValueProperty() { > ??????? return myValue; > ??? } > > It is not required to override the `getCssMetaData()` method, nor is > it required to redeclare a new static `getClassCssMetaData()` method. > It is also not required to manually keep the list of styleable > properties in sync with the list of CSS metadata. > > I've prototyped this concept for the `Node`, `Region` and > `Control` classes [1]. > > [0] > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044046.html > [1] https://github.com/openjdk/jfx/pull/1299 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.sayao at gmail.com Wed Dec 6 13:42:35 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Wed, 6 Dec 2023 10:42:35 -0300 Subject: Reflective discovery of styleable properties In-Reply-To: <3cfd7806-45c1-1d52-2f78-c0ab1c5076cf@gmail.com> References: <3cfd7806-45c1-1d52-2f78-c0ab1c5076cf@gmail.com> Message-ID: Hi, Maybe it could generate the boilerplate like Lombok does? So it has the benefits of eliminating error-prone boilerplate code and the benefits of not having the cost of reflection at runtime. -- Thiago. Em qua., 6 de dez. de 2023 ?s 10:28, John Hendrikx escreveu: > I also like this route, perhaps slightly more, depending on how far this > can be taken: > > Disclaimer: I dislike the CSSMetaData and special property subclass a lot > -- it's a major concession to make properties work with the CSS system that > brings a lot of boilerplate that is mostly unnecessary. > > If you go the route of an annotation, we could offer to do everything via > the annotation so a regular property can be converted to styleable by > annotating it. The property would then have to specify the name > ("-fx-label-padding") and the default value (which can be a string that is > parseable via the existing CSS parser). > > In other words: > > @Styleable(name = "-fx-label-padding", defaultValue = "(0, 0, 0, 0)") > public final ReadOnlyObjectProperty labelPaddingProperty() { ... } > The rest the scanner can figure out (it could even figure out a default > name). The `isSettable` method is always the same boilerplate (and if not, > you can use the old way). The required converter can be derived from the > generic type (Insets -> InsetsConverter), or specified (converter = > InsetsConverter.class). > > To convert a regular property into a styleable does require somewhat more > magic (the CSS system would have to wrap it, or otherwise track them) but > that's all hidden. It gets rid of the StyleableProperty uglyness and the > need for users to create those, and puts the "extra" CSSMetaData > information a styleable property needs firmly where it belongs (in an > annotation). > > --John > > On 06/12/2023 11:37, Nir Lisker wrote: > > I thought about the option of reflection, but I opted to propose > annotations instead. The following is my reasoning. > > Firstly, reflection is very magic-y. The author of the class has no > indication of what side effects happen due to the code they write, the > output (css handling in this case) comes out of nowhere from their > perspective. As with other reflection cases, it is a "pull" rather than > "push" approach - you don't write what should happen, you let someone else > decide that. For writers of skin/control classes, this means that they need > to know exactly what constitutes a hook for the reflection mechanism, or > face surprises. There is no compile time check that tells you whether you > have declared your styleable property properly or not (without an external > ad-hoc checker). > We do this somewhat with properties - any method of the form > "...property()" gets special treatment, but this is for the docs. I don't > think we have code that depends on this other than in tests. > > Secondly, the proposed mechanism depends on the runtime type, not the > declared type. As a user, I see no indication in the API whether a property > is styleable or not. This is also (what I would consider) a problem with > the current state. When I thought about using reflection to solve this, I > at least thought to specify the declared type of the property as styleable, > like StyleableBooleanProperty instead of BooleanProperty (restricting the > returned type is backwards compatible). A downside of this is that it gives > access to the methods of StyleableProperty, which are not useful for the > user, I think, but maybe someone has a use for them. > > Thirdly, maybe I want to declare a styleable property not to be used > automatically. I can't think off the top of my head when I would want to do > that, but I'm also not a heavy css user. Are we sure that just initializing > a property with a styleable runtime type should *always* be caught by this > process? > > To compare, annotations have the following benefits: > > Firstly, they are declarative, which means no surprises for the class > author (WYSIWYG). This also allows more flexibility/control over which > properties get special treatment via an opt-in mechanism. > > Secondly, They can also be displayed in the JavaDocs (via @Documented) > with their assigned values. For example, the padding property of Region can > be annotated with @Styleable(property="-fx-padding"), informing the user > both that this value can be set by css, and how to do it. Interestingly, > the annotation doesn't need to be public API to be displayed, so we are not > bound by contracts. > > In terms of similarities: > > In both the reflection and the annotation proposals, the steps are: > 1. Create styleable properties. > 2. That's it. > It's just that step 1 also adds an annotation to the creation of the > property (which was/is a 2-step process anyway, declaring the property and > its css metadata). > > Annotations also require a processor to read the data from their values > and target (the field/method). This is a bit of work, but > Michael's CssMetaDataCache class is basically that - read the data from the > class (via reflection or annotations) and store it in a map. The logic > should be the same, just the method to obtain the data is different. Both, > as a result, have the benefits of handling control/skin combinations (what > I mentioned in the point "Usable both in controls and in skins (or other > classes)"). > > The benefit of co-locating the property and its css metadata in the class > itself also remains. > > > To summarize, both approaches eliminate all the clutter of writing > styleable properties (John, will you like to create styleable properties > now? [1] :) ), both apply the flexibility of caching per class, both allow > better structuring of the class, but they read the properties differently > and have a different level of declarativness. > > [1] > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044010.html > > > On Tue, Dec 5, 2023 at 11:21?PM Andy Goryachev > wrote: > >> I like the idea. >> >> >> >> I wonder if it is possible to reduce the amount of boilerplate code? For >> example, a CssMetaData can have a >> >> >> >> setGetter(Function> getter) >> >> >> >> method which supplies the property reference? This way >> CssMetaData.isSettable(Node) and CssMetaData.getStyleableProperty(Node) can >> be implemented in the base class (there are more complicated cases, so >> perhaps setIsSettable(Predicate) would also be required). >> >> >> >> Example: >> >> >> >> CssMetaData.of("-fx-font", Font.getDefault(), (n) >> -> n.font) >> >> >> >> Just a thought. What do you think? >> >> >> >> -andy >> >> >> >> >> >> *From: *openjfx-dev on behalf of Michael >> Strau? >> *Date: *Sunday, December 3, 2023 at 22:02 >> *To: *openjfx-dev >> *Subject: *Reflective discovery of styleable properties >> >> Following up the discussion around the CssMetaData API, I'd like to >> chime in with yet another idea. To recap, here's Nir's summary of the >> current API [0]: >> >> "Let's look at what implementation is required from a user who wants >> to write their own styleable control: >> 1. Create styleable properties. >> 2. Create a list of these properties to be passed on. >> 3. Create a public static method that returns the concatenation of >> this list with the one of its parent. (This method happens to be >> poorly documented, as mstr said.) >> 4. Create a public non-static method that calls the static method in a >> forced-override pattern because otherwise you will be calling the >> wrong static method. (This method's docs seem to be just wrong because >> you don't always want to delegate to Node's list.)" >> >> >> I think this could reasonably be replaced with the following >> implementation requirements: >> 1. Create styleable properties. >> 2. That's it. >> >> Let's look at what we're actually trying to do: create a list of >> CSS-styleable property metadata of a class. But we can easily do that >> without all of the boilerplate code. >> >> When ?Node.getCssMetaData()` is invoked, all public methods of the >> class are reflectively enumerated, and metadata is retrieved from >> `Property` and `StyleableProperty` getters. This is a price that's >> only paid once for any particular class (i.e. not for every instance). >> The resulting metadata list is cached and reused for all instances of >> that particular class. >> >> As a further optimization, metadata lists are also cached and >> deduplicated for Control/Skin combinations (currently every Control >> instance has its own copy of the metadata list). >> >> Another benefit of this approach is that the CssMetaData can now be >> co-located with the property implementation, and not be kept around in >> other parts of the source code file. Here's how that looks like when a >> new "myValue" property is added to MyClass: >> >> StyleableDoubleProperty myValue = >> new SimpleStyleableDoubleProperty(this, "myValue") { >> >> static final CssMetaData METADATA = >> new CssMetaData( >> "-fx-my-value", >> SizeConverter.getInstance(), >> USE_COMPUTED_SIZE) { >> @Override >> public boolean isSettable(MyClass node) { >> return !node.myValue.isBound(); >> } >> >> @Override >> public StyleableProperty getStyleableProperty( >> MyClass node) { >> return node.myValue; >> } >> }; >> >> @Override >> public CssMetaData getCssMetaData() { >> return METADATA; >> } >> }; >> >> public final DoubleProperty myValueProperty() { >> return myValue; >> } >> >> It is not required to override the `getCssMetaData()` method, nor is >> it required to redeclare a new static `getClassCssMetaData()` method. >> It is also not required to manually keep the list of styleable >> properties in sync with the list of CSS metadata. >> >> I've prototyped this concept for the `Node`, `Region` and `Control` >> classes [1]. >> >> [0] >> https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044046.html >> [1] https://github.com/openjdk/jfx/pull/1299 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsayao at openjdk.org Wed Dec 6 14:21:57 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 6 Dec 2023 14:21:57 GMT Subject: RFR: 8319340: [Linux] Disabled windows should not allow window operations (minimize, resize, maximize, close) [v3] In-Reply-To: References: Message-ID: > JavaFX on Linux is allowing disabled windows to be minimized. > > Currently close does nothing as it should, maximize disappears (on MS Windows it's greyed out - it's a platform behavior difference) and minimize is being allowed. > > Thins PR removes WM functions when window is disabled and restores it back when it's re-enabled. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1278/files - new: https://git.openjdk.org/jfx/pull/1278/files/1d58a508..ccd09fa8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1278&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1278&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1278.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1278/head:pull/1278 PR: https://git.openjdk.org/jfx/pull/1278 From andy.goryachev at oracle.com Wed Dec 6 16:06:01 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 6 Dec 2023 16:06:01 +0000 Subject: eclipse warnings In-Reply-To: References: <24f4a015-4093-496b-81a1-0d972f9bd686@oracle.com> Message-ID: Dear Johan: What would be your best recommendation to minimize the burden? Split into small PRs on a per-module or per-package basis? Thanks, -andy From: openjfx-dev on behalf of Johan Vos Date: Monday, December 4, 2023 at 09:25 To: Kevin Rushforth Cc: openjfx-dev at openjdk.org Subject: Re: eclipse warnings Also, these commits often affect many files at once (in scattered locations), and that makes backports harder. - Johan On Mon, Dec 4, 2023 at 6:14?PM Kevin Rushforth > wrote: We did a few of these sort of cleanup fixes a year or so ago. In general, this sort of cleanup *might* be useful, but also causes some code churn and takes review cycles to ensure that there is no unintentional side effect. The last two might be OK cleanup tasks, but I wouldn't make them a high priority. Worth noting is that a seemingly redundant null check or instanceof check is not always a bad thing, so I wouldn't clean up all of them. The first group is the more interesting one. In some cases a potential null access can highlight actual bugs. However, I oppose any automated solution for these, since adding a null check where you don't expect a null (even if you IDE thinks it might be possible) can hide the root cause of a problem. We aren't going to enforce these, though, so you'll likely need to configure your IDE to be less picky. -- Kevin On 12/4/2023 8:34 AM, Andy Goryachev wrote: Dear colleagues: Imported the openjfx project into another workspace with a more stringent error checking and discovered a few issues: * potential null pointer access: 295 * unnecessary cast or instanceof: 190 * redundant null check: 61 Do we want to clean these up? -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Wed Dec 6 16:21:30 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 6 Dec 2023 16:21:30 +0000 Subject: [External] : Re: Reflective discovery of styleable properties In-Reply-To: References: Message-ID: I also like this idea very much. Still needs a reflective scanner, but it's far more easier to understand and use. A couple of comments/questions: - I would recommend against the scanner figuring out the property name: the property names are codified by the CSS reference which serves as a normative document in this case - isSettable() logic might be more complex than (prop == null && !(prop.isBound)), see Node.translateXProperty. How would that work with annotations? What do you think? -andy From: Nir Lisker Date: Wednesday, December 6, 2023 at 02:37 To: Andy Goryachev Cc: Michael Strau? , openjfx-dev Subject: [External] : Re: Reflective discovery of styleable properties I thought about the option of reflection, but I opted to propose annotations instead. The following is my reasoning. Firstly, reflection is very magic-y. The author of the class has no indication of what side effects happen due to the code they write, the output (css handling in this case) comes out of nowhere from their perspective. As with other reflection cases, it is a "pull" rather than "push" approach - you don't write what should happen, you let someone else decide that. For writers of skin/control classes, this means that they need to know exactly what constitutes a hook for the reflection mechanism, or face surprises. There is no compile time check that tells you whether you have declared your styleable property properly or not (without an external ad-hoc checker). We do this somewhat with properties - any method of the form "...property()" gets special treatment, but this is for the docs. I don't think we have code that depends on this other than in tests. Secondly, the proposed mechanism depends on the runtime type, not the declared type. As a user, I see no indication in the API whether a property is styleable or not. This is also (what I would consider) a problem with the current state. When I thought about using reflection to solve this, I at least thought to specify the declared type of the property as styleable, like StyleableBooleanProperty instead of BooleanProperty (restricting the returned type is backwards compatible). A downside of this is that it gives access to the methods of StyleableProperty, which are not useful for the user, I think, but maybe someone has a use for them. Thirdly, maybe I want to declare a styleable property not to be used automatically. I can't think off the top of my head when I would want to do that, but I'm also not a heavy css user. Are we sure that just initializing a property with a styleable runtime type should *always* be caught by this process? To compare, annotations have the following benefits: Firstly, they are declarative, which means no surprises for the class author (WYSIWYG). This also allows more flexibility/control over which properties get special treatment via an opt-in mechanism. Secondly, They can also be displayed in the JavaDocs (via @Documented) with their assigned values. For example, the padding property of Region can be annotated with @Styleable(property="-fx-padding"), informing the user both that this value can be set by css, and how to do it. Interestingly, the annotation doesn't need to be public API to be displayed, so we are not bound by contracts. In terms of similarities: In both the reflection and the annotation proposals, the steps are: 1. Create styleable properties. 2. That's it. It's just that step 1 also adds an annotation to the creation of the property (which was/is a 2-step process anyway, declaring the property and its css metadata). Annotations also require a processor to read the data from their values and target (the field/method). This is a bit of work, but Michael's CssMetaDataCache class is basically that - read the data from the class (via reflection or annotations) and store it in a map. The logic should be the same, just the method to obtain the data is different. Both, as a result, have the benefits of handling control/skin combinations (what I mentioned in the point "Usable both in controls and in skins (or other classes)"). The benefit of co-locating the property and its css metadata in the class itself also remains. To summarize, both approaches eliminate all the clutter of writing styleable properties (John, will you like to create styleable properties now? [1] :) ), both apply the flexibility of caching per class, both allow better structuring of the class, but they read the properties differently and have a different level of declarativness. [1] https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044010.html On Tue, Dec 5, 2023 at 11:21?PM Andy Goryachev > wrote: I like the idea. I wonder if it is possible to reduce the amount of boilerplate code? For example, a CssMetaData can have a setGetter(Function> getter) method which supplies the property reference? This way CssMetaData.isSettable(Node) and CssMetaData.getStyleableProperty(Node) can be implemented in the base class (there are more complicated cases, so perhaps setIsSettable(Predicate) would also be required). Example: CssMetaData.of("-fx-font", Font.getDefault(), (n) -> n.font) Just a thought. What do you think? -andy From: openjfx-dev > on behalf of Michael Strau? > Date: Sunday, December 3, 2023 at 22:02 To: openjfx-dev > Subject: Reflective discovery of styleable properties Following up the discussion around the CssMetaData API, I'd like to chime in with yet another idea. To recap, here's Nir's summary of the current API [0]: "Let's look at what implementation is required from a user who wants to write their own styleable control: 1. Create styleable properties. 2. Create a list of these properties to be passed on. 3. Create a public static method that returns the concatenation of this list with the one of its parent. (This method happens to be poorly documented, as mstr said.) 4. Create a public non-static method that calls the static method in a forced-override pattern because otherwise you will be calling the wrong static method. (This method's docs seem to be just wrong because you don't always want to delegate to Node's list.)" I think this could reasonably be replaced with the following implementation requirements: 1. Create styleable properties. 2. That's it. Let's look at what we're actually trying to do: create a list of CSS-styleable property metadata of a class. But we can easily do that without all of the boilerplate code. When ?Node.getCssMetaData()` is invoked, all public methods of the class are reflectively enumerated, and metadata is retrieved from `Property` and `StyleableProperty` getters. This is a price that's only paid once for any particular class (i.e. not for every instance). The resulting metadata list is cached and reused for all instances of that particular class. As a further optimization, metadata lists are also cached and deduplicated for Control/Skin combinations (currently every Control instance has its own copy of the metadata list). Another benefit of this approach is that the CssMetaData can now be co-located with the property implementation, and not be kept around in other parts of the source code file. Here's how that looks like when a new "myValue" property is added to MyClass: StyleableDoubleProperty myValue = new SimpleStyleableDoubleProperty(this, "myValue") { static final CssMetaData METADATA = new CssMetaData( "-fx-my-value", SizeConverter.getInstance(), USE_COMPUTED_SIZE) { @Override public boolean isSettable(MyClass node) { return !node.myValue.isBound(); } @Override public StyleableProperty getStyleableProperty( MyClass node) { return node.myValue; } }; @Override public CssMetaData getCssMetaData() { return METADATA; } }; public final DoubleProperty myValueProperty() { return myValue; } It is not required to override the `getCssMetaData()` method, nor is it required to redeclare a new static `getClassCssMetaData()` method. It is also not required to manually keep the list of styleable properties in sync with the list of CSS metadata. I've prototyped this concept for the `Node`, `Region` and `Control` classes [1]. [0] https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044046.html [1] https://github.com/openjdk/jfx/pull/1299 -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Wed Dec 6 16:41:35 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 6 Dec 2023 17:41:35 +0100 Subject: Reflective discovery of styleable properties In-Reply-To: References: <3cfd7806-45c1-1d52-2f78-c0ab1c5076cf@gmail.com> Message-ID: <0b448c30-712b-05ba-27f8-695785430fe0@gmail.com> You mean using an annotation processor? These can actually only create new types; modifying an existing one like Lombok is doing is illegal (the original source code with Lombok annotations is not plain Java anymore, hence an IDE plugin is required for IDE's to understand it). Still, a lot is possible.? I really like RecordBuilder (https://github.com/Randgalt/record-builder) -- it provide builders for records (in a seperate type named `Builder`) and if your record implements `Builder.With`, you even get wither methods courtesy of the default methods on the generated interface `Builder.With`. --John On 06/12/2023 14:42, Thiago Milczarek Say?o wrote: > Hi, > > Maybe it could generate the boilerplate like Lombok does? > So it has the benefits of eliminating?error-prone boilerplate code and > the benefits of not having the cost of reflection at runtime. > > -- Thiago. > > > Em qua., 6 de dez. de 2023 ?s 10:28, John Hendrikx > escreveu: > > I also like this route, perhaps slightly more, depending on how > far this can be taken: > > Disclaimer: I dislike the CSSMetaData and special property > subclass a lot -- it's a major concession to make properties work > with the CSS system that brings a lot of boilerplate that is > mostly unnecessary. > > If you go the route of an annotation, we could offer to do > everything via the annotation so a regular property can be > converted to styleable by annotating it.? The property would then > have to specify the name ("-fx-label-padding") and the default > value (which can be a string that is parseable via the existing > CSS parser). > > In other words: > > @Styleable(name = "-fx-label-padding", defaultValue = "(0, 0, 0, > 0)") publicfinalReadOnlyObjectProperty > labelPaddingProperty() { ... } > > The rest the scanner can figure out (it could even figure out a > default name). The `isSettable` method is always the same > boilerplate (and if not, you can use the old way).? The required > converter can be derived from the generic type (Insets -> > InsetsConverter), or specified (converter = InsetsConverter.class). > > To convert a regular property into a styleable does require > somewhat more magic (the CSS system would have to wrap it, or > otherwise track them) but that's all hidden. It gets rid of the > StyleableProperty uglyness and the need for users to create those, > and puts the "extra" CSSMetaData information a styleable property > needs firmly where it belongs (in an annotation). > > --John > > On 06/12/2023 11:37, Nir Lisker wrote: >> I thought about the option of reflection, but I opted?to propose >> annotations instead. The following is my reasoning. >> >> Firstly, reflection is very magic-y. The author of the class has >> no indication of what side effects happen due to the code they >> write, the output (css handling in this case) comes out of >> nowhere from their perspective. As with other reflection cases, >> it is a "pull" rather than "push" approach - you don't write what >> should happen, you let someone else decide?that. For writers of >> skin/control classes, this means that they need to know exactly >> what constitutes?a hook for the reflection mechanism, or face >> surprises. There is no compile time check that tells you whether >> you have declared your styleable property properly or not >> (without an external ad-hoc checker). >> We do this somewhat with properties - any method of the form >> "...property()" gets special treatment, but this is for the docs. >> I don't think we have code that depends on this other than in tests. >> >> Secondly, the proposed mechanism depends on the runtime type, not >> the declared type. As a user, I see no indication in the API >> whether a property is styleable or not. This is also (what I >> would consider) a problem with the current state. When I thought >> about using reflection to solve this, I at least thought to >> specify the declared type of the property as styleable, like >> StyleableBooleanProperty instead of BooleanProperty (restricting >> the returned type is backwards compatible). A downside of this is >> that it gives access to the methods of StyleableProperty, which >> are not useful for the user, I think, but maybe someone has a use >> for them. >> >> Thirdly, maybe I want to declare a styleable property?not to be >> used automatically. I can't think off the top of my head when I >> would want to do that, but I'm also not a heavy css user. Are we >> sure that just initializing a property with a styleable runtime >> type should *always* be caught by this process? >> >> To compare, annotations have the following benefits: >> >> Firstly, they are declarative, which means no surprises for the >> class author (WYSIWYG). This also allows more flexibility/control >> over which properties get special treatment via an opt-in mechanism. >> >> Secondly, They can also be displayed in the JavaDocs >> (via?@Documented) with their assigned values. For example, the >> padding property of Region can be annotated >> with?@Styleable(property="-fx-padding"), informing the user both >> that this value can be set by css, and how to do it. >> Interestingly, the annotation doesn't need to be public API to be >> displayed, so we are not bound by contracts. >> >> In terms of similarities: >> >> In both the reflection and the annotation proposals, the steps are: >> 1. Create styleable properties. >> 2. That's it. >> It's just that step 1 also adds an annotation to the creation of >> the property (which was/is a 2-step process anyway, declaring the >> property and its?css metadata). >> >> Annotations also require a processor to read the data from their >> values and target (the field/method). This is a bit of work, but >> Michael's?CssMetaDataCache class is basically that - read the >> data from the class (via reflection or annotations) and store it >> in a map. The logic should be the same, just the method to obtain >> the data is different. Both, as a result, have the benefits of >> handling control/skin combinations (what I mentioned in the point >> "Usable both in controls and in skins (or other classes)"). >> >> The benefit of co-locating the property and its css metadata in >> the class itself also remains. >> >> >> To summarize, both approaches eliminate all the clutter of >> writing styleable properties (John, will you like to create >> styleable properties now? [1] :) ), both apply the flexibility of >> caching per class, both allow better structuring of the class, >> but they read the properties differently and have a different >> level of declarativness. >> >> [1] >> https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044010.html >> >> >> On Tue, Dec 5, 2023 at 11:21?PM Andy Goryachev >> wrote: >> >> I like the idea. >> >> I wonder if it is possible to reduce the amount of >> boilerplate code?? For example, a CssMetaData can have a >> >> setGetter(Function> getter) >> >> method which supplies the property reference?? This way >> CssMetaData.isSettable(Node) and >> CssMetaData.getStyleableProperty(Node) can be implemented in >> the base class (there are more complicated cases, so perhaps >> setIsSettable(Predicate) would also be required). >> >> Example: >> >> CssMetaData.of("-fx-font", >> Font.getDefault(), (n) -> n.font) >> >> Just a thought.? What do you think? >> >> -andy >> >> *From: *openjfx-dev on behalf >> of Michael Strau? >> *Date: *Sunday, December 3, 2023 at 22:02 >> *To: *openjfx-dev >> *Subject: *Reflective discovery of styleable properties >> >> Following up the discussion around the CssMetaData API, I'd >> like to >> chime in with yet another idea. To recap, here's Nir's >> summary of the >> current API [0]: >> >> "Let's look at what implementation is required from a user >> who wants >> to write their own styleable control: >> 1. Create styleable properties. >> 2. Create a list of these properties to be passed on. >> 3. Create a public static method that returns the >> concatenation of >> this list with the one of its parent. (This method happens to be >> poorly documented, as mstr said.) >> 4. Create a public non-static method that calls the static >> method in a >> forced-override pattern because otherwise you will be calling the >> wrong static method. (This method's docs seem to be just >> wrong because >> you don't always want to delegate to Node's list.)" >> >> >> I think this could reasonably be replaced with the following >> implementation requirements: >> 1. Create styleable properties. >> 2. That's it. >> >> Let's look at what we're actually trying to do: create a list of >> CSS-styleable property metadata of a class. But we can easily >> do that >> without all of the boilerplate code. >> >> When ?Node.getCssMetaData()` is invoked, all public methods >> of the >> class are reflectively enumerated, and metadata is retrieved from >> `Property` and `StyleableProperty` getters. This is a price >> that's >> only paid once for any particular class (i.e. not for every >> instance). >> The resulting metadata list is cached and reused for all >> instances of >> that particular class. >> >> As a further optimization, metadata lists are also cached and >> deduplicated for Control/Skin combinations (currently every >> Control >> instance has its own copy of the metadata list). >> >> Another benefit of this approach is that the CssMetaData can >> now be >> co-located with the property implementation, and not be kept >> around in >> other parts of the source code file. Here's how that looks >> like when a >> new "myValue" property is added to MyClass: >> >> ??? StyleableDoubleProperty myValue = >> ??????????? new SimpleStyleableDoubleProperty(this, "myValue") { >> >> ??????? static final CssMetaData METADATA = >> ??????????? new CssMetaData( >> ??????????????? "-fx-my-value", >> SizeConverter.getInstance(), >> ??????????????? USE_COMPUTED_SIZE) { >> ??????????? @Override >> ??????????? public boolean isSettable(MyClass node) { >> ??????????????? return !node.myValue.isBound(); >> ??????????? } >> >> ??????????? @Override >> ??????????? public StyleableProperty getStyleableProperty( >> ??????????????????? MyClass node) { >> ??????????????? return node.myValue; >> ??????????? } >> ??????? }; >> >> ??????? @Override >> ??????? public CssMetaData getCssMetaData() { >> ??????????? return METADATA; >> ??????? } >> ??? }; >> >> ??? public final DoubleProperty myValueProperty() { >> ??????? return myValue; >> ??? } >> >> It is not required to override the `getCssMetaData()` method, >> nor is >> it required to redeclare a new static `getClassCssMetaData()` >> method. >> It is also not required to manually keep the list of styleable >> properties in sync with the list of CSS metadata. >> >> I've prototyped this concept for the `Node`, `Region` and >> `Control` classes [1]. >> >> [0] >> https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044046.html >> [1] https://github.com/openjdk/jfx/pull/1299 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Wed Dec 6 18:41:29 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Dec 2023 18:41:29 GMT Subject: RFR: 8301302: Platform preferences API [v40] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Dec 2023 00:52:32 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - null checking > - rename GLASS_CHECK_EXCEPTIONALLY_RETURN I retested (sanity test) and all looks good. I left one comment about a change that I think is needed to one of the error checks you added. The rest looks good. modules/javafx.graphics/src/main/native-glass/win/RoActivationSupport.cpp line 208: > 206: int message_length = int(strlen(message)); > 207: int error_length = WideCharToMultiByte(CP_ACP, 0, error, -1, NULL, 0, NULL, FALSE); > 208: if (message_length + error_length == 0) return; Unless I'm missing something, this test should just be `if (error_length == 0)` -- note that a 0 value indicates an error (since the count includes the null terminator). The concern is that if `WideCharToMultiByte` returns a 0, then you will construct a string with no null terminator, since the subsequent call to `WideCharToMultiByte` would do nothing and you (intentionally) don't copy the null terminator from the message. ------------- PR Review: https://git.openjdk.org/jfx/pull/1014#pullrequestreview-1768319891 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1417794955 From mstrauss at openjdk.org Wed Dec 6 19:14:43 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Dec 2023 19:14:43 GMT Subject: RFR: 8301302: Platform preferences API [v41] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <-x_eM2O14qV5DXv_zh-0SQaK4ksDbfifdOmetXOQDCw=.6cf67d9e-1d38-4020-91e5-5e5ec26cfcbc@github.com> > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: changed error condition check ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/db393fca..0759ddd0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=40 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=39-40 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Wed Dec 6 19:14:45 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Dec 2023 19:14:45 GMT Subject: RFR: 8301302: Platform preferences API [v28] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Mon, 20 Nov 2023 19:24:03 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Support polymorphic values > > I feel that the gist mentioned in the description (https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548 ) has value for the application developers (after updating it with the current detail), but once this PR is integrated it will be hard to find (and located in a private repository). > > There is a bit of overlap between the gist and the CSR, but CSR has a much narrower focus. > > It is my personal opinion that the gist should be moved to doc-files/jeps or doc-files/application-notes, in other words, in the documents in the repo. > > If I recall correctly, @kevinrushforth is against this idea, saying that documentation belongs in a wiki somewhere, but I disagree. Markdown is a good format that provides a reasonably nice visual rendering and is compatible with the code review tooling, so it can be reviewed as a part of the code review. I don't like wikis in general because they become obsolete quickly, are hard to maintain, and are not linked with the code. > > What do you think? @andy-goryachev-oracle @hjohn Can you re-approve? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1843534222 From mstrauss at openjdk.org Wed Dec 6 19:14:49 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Dec 2023 19:14:49 GMT Subject: RFR: 8301302: Platform preferences API [v40] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Dec 2023 18:13:42 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: >> >> - null checking >> - rename GLASS_CHECK_EXCEPTIONALLY_RETURN > > modules/javafx.graphics/src/main/native-glass/win/RoActivationSupport.cpp line 208: > >> 206: int message_length = int(strlen(message)); >> 207: int error_length = WideCharToMultiByte(CP_ACP, 0, error, -1, NULL, 0, NULL, FALSE); >> 208: if (message_length + error_length == 0) return; > > Unless I'm missing something, this test should just be `if (error_length == 0)` -- note that a 0 value indicates an error (since the count includes the null terminator). The concern is that if `WideCharToMultiByte` returns a 0, then you will construct a string with no null terminator, since the subsequent call to `WideCharToMultiByte` would do nothing and you (intentionally) don't copy the null terminator from the message. Yes, I think that's right. Changed it accordingly. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1417863223 From mstrauss at openjdk.org Wed Dec 6 19:23:38 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Dec 2023 19:23:38 GMT Subject: RFR: 8301302: Platform preferences API [v42] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: consistently use NULL ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/0759ddd0..a2bd32d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=41 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=40-41 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From angorya at openjdk.org Wed Dec 6 19:36:27 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Dec 2023 19:36:27 GMT Subject: RFR: 8301302: Platform preferences API [v42] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Dec 2023 19:23:38 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > consistently use NULL Looks like it's sending changes for values that have not changed: Screenshot 2023-12-06 at 11 30 04 To reproduce on macOS 13.5.2: change System Settings -> Appearance -> Accent Color from green to yellow. I don't expect `macOS.NSColor.alternatingContentBackgroundColors=[0xffffffff, 0xf4f5f5ff]` to be sent because it has not changed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1843564085 From jpereda at openjdk.org Wed Dec 6 19:50:22 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Dec 2023 19:50:22 GMT Subject: RFR: 8301302: Platform preferences API [v42] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Dec 2023 19:23:38 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > consistently use NULL I am testing `PlatformPreferencesChangedTest` on Windows 11 22H2 22621.2715 (English setup). I run the app, with no contrast theme, and I see the default colours: preferences = { Windows.SPI.HighContrastOn=false Windows.SysColor.COLOR_3DFACE=0xf0f0f0ff ... Windows.UIColor.Foreground=0x000000ff } Note I get the preference `Windows.SPI.HighContrastOn`, which is not listed in the javadoc of `javafx.application.Platform.Preferences`, but I don't get these two preferences which are listed: Windows.SPI.HighContrast Windows.SPI.HighContrastColorScheme I take that `PlatformPreferences` doesn't list those if the high contrast mode is off. Then I go to Settings->Accessibility->Contrast themes, select Aquatic, and I see the change: changed = { Windows.SysColor.COLOR_3DFACE=0x202020ff ... Windows.UIColor.Foreground=0xffffffff } (still no SPI preferences). The app only changes the window frame (to yellow), and I see this exception: Exception in thread "JavaFX Application Thread" java.lang.IllegalArgumentException: No enum constant com.sun.javafx.application.PlatformImpl.HighContrastScheme.High Contrast Black at java.base/java.lang.Enum.valueOf(Enum.java:273) at javafx.graphics at 22-internal/com.sun.javafx.application.PlatformImpl$HighContrastScheme.valueOf(PlatformImpl.java:738) at javafx.graphics at 22-internal/com.sun.javafx.application.PlatformImpl._setAccessibilityTheme(PlatformImpl.java:826) at javafx.graphics at 22-internal/com.sun.javafx.application.PlatformImpl.setAccessibilityTheme(PlatformImpl.java:786) at javafx.graphics at 22-internal/com.sun.javafx.application.PlatformImpl.checkHighContrastThemeChanged(PlatformImpl.java:1097) at javafx.graphics at 22-internal/com.sun.javafx.application.PlatformImpl.updatePreferences(PlatformImpl.java:1083) at javafx.graphics at 22-internal/com.sun.javafx.tk.quantum.QuantumToolkit$2.handlePreferencesChanged(QuantumToolkit.java:375) at javafx.graphics at 22-internal/com.sun.glass.ui.Application.notifyPreferencesChanged(Application.java:264) ``` With some debugging, I can see that the new Preferences map passed to `PlatformImpl::checkHighContrastThemeChanged` does have `Windows.SPI.HighContrastColorScheme -> High Contrast Black` and therefore `High Contrast Black` is passed now, instead of the existing key `high.contrast.black.theme` in `PlatformImpl::HighContrastScheme`, which causes the above exception. The same happens applying the `desert` contrast theme: error finding `PlatformImpl.HighContrastScheme.High Contrast White` instead of `high.contrast.white.theme`, the `dusk` contrast theme -> `PlatformImpl.HighContrastScheme.High Contrast #1` instead of `high.contrast.1.theme` and or the `night sky` contrast theme -> `PlatformImpl.HighContrastScheme.High Contrast #2` instead of `high.contrast.2.theme`. So I guess we'll need to review this `HighContrastScheme` enum. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1843583231 From angorya at openjdk.org Wed Dec 6 20:03:28 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Dec 2023 20:03:28 GMT Subject: RFR: 8301302: Platform preferences API [v42] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Dec 2023 19:23:38 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > consistently use NULL macOS again, System Settings -> Accessibility -> Display should an update be sent when changing - invert colors - increase contrast - display contrast (this seems to affect display's gamma, so probably not) Screenshot 2023-12-06 at 11 56 09 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1843600341 From kcr at openjdk.org Wed Dec 6 20:03:31 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Dec 2023 20:03:31 GMT Subject: RFR: 8301302: Platform preferences API [v39] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <4b5ntMAevRGKg7QTxKxT-v8CV7ddeWMtgTA8_jT0aGQ=.7a0725f1-637e-41eb-a7ca-537bd740f9e1@github.com> Message-ID: On Wed, 6 Dec 2023 01:02:55 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/native-glass/win/RoActivationSupport.cpp line 213: >> >>> 211: RoException& RoException::operator=(RoException source) >>> 212: { >>> 213: std::swap(*this, source); >> >> Did you mean to do the swap here? > > Yes. This is the copy-and-swap idiom, where the copy is made by using a pass-by-value parameter. I see. I did happen to spot this compiler warning while compiling: .../VC/bin/x64/cl.exe /nologo /W3 /EHsc /c /DINLINE=__inline /DUNICODE /D_UNICODE /DWIN32 /DIAL /D_LITTLE_ENDIAN /DWIN32_LEAN_AND_MEAN /IC:/Users/kcr/dev/jdks/jdk-19.0.2/include /I.../jdk-19.0.2/include/win32 /O2 /MD /DNDEBUG -Imodules\javafx.graphics\build\gensrc\headers\javafx.graphics -Imodules\javafx.graphics\src\main\native-glass\win /Fomodules\javafx.graphics\build\native\glass\win\RoActivationSupport.obj modules\javafx.graphics\src\main\native-glass\win\RoActivationSupport.cpp VC\include\utility(103) : warning C4717: 'std::swap': recursive on all control paths, function will cause runtime stack overflow modules\javafx.graphics\src\main\native-glass\win\RoActivationSupport.cpp(233) : warning C4717: 'RoException::operator=': recursive on all control paths, function will cause runtime stack overflow you can see that in your GHA build as well. I don't know for certain whether this is a problem in practice or not, but it would be good to eliminate the warning. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1417913075 From mstrauss at openjdk.org Wed Dec 6 20:38:46 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Dec 2023 20:38:46 GMT Subject: RFR: 8301302: Platform preferences API [v43] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: swap message fields ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/a2bd32d2..070eab54 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=42 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=41-42 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Wed Dec 6 20:38:47 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Dec 2023 20:38:47 GMT Subject: RFR: 8301302: Platform preferences API [v39] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <4b5ntMAevRGKg7QTxKxT-v8CV7ddeWMtgTA8_jT0aGQ=.7a0725f1-637e-41eb-a7ca-537bd740f9e1@github.com> Message-ID: <_wH_M8B_qOYGY7_SL3l6LwyYESOxoWUQlazM6AeCeZk=.9917bc43-1e88-4e3b-acc6-f9a93c6b82b6@github.com> On Wed, 6 Dec 2023 19:59:25 GMT, Kevin Rushforth wrote: >> Yes. This is the copy-and-swap idiom, where the copy is made by using a pass-by-value parameter. > > I see. > > I did happen to spot this compiler warning while compiling: > > > .../VC/bin/x64/cl.exe /nologo /W3 /EHsc /c /DINLINE=__inline /DUNICODE /D_UNICODE /DWIN32 /DIAL /D_LITTLE_ENDIAN /DWIN32_LEAN_AND_MEAN /IC:/Users/kcr/dev/jdks/jdk-19.0.2/include /I.../jdk-19.0.2/include/win32 /O2 /MD /DNDEBUG -Imodules\javafx.graphics\build\gensrc\headers\javafx.graphics -Imodules\javafx.graphics\src\main\native-glass\win /Fomodules\javafx.graphics\build\native\glass\win\RoActivationSupport.obj modules\javafx.graphics\src\main\native-glass\win\RoActivationSupport.cpp > VC\include\utility(103) : warning C4717: 'std::swap': recursive on all control paths, function will cause runtime stack overflow > modules\javafx.graphics\src\main\native-glass\win\RoActivationSupport.cpp(233) : warning C4717: 'RoException::operator=': recursive on all control paths, function will cause runtime stack overflow > > > you can see that in your GHA build as well. I don't know for certain whether this is a problem in practice or not, but it would be good to eliminate the warning. I can fix this by swapping the `message_` fields directly, which doesn't change the logic of the copy-and-swap. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1417949026 From mstrauss at openjdk.org Wed Dec 6 21:31:36 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Dec 2023 21:31:36 GMT Subject: RFR: 8301302: Platform preferences API [v44] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: fixed bug in test application ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/070eab54..515395b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=43 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=42-43 Stats: 24 lines in 1 file changed: 8 ins; 9 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From kcr at openjdk.org Wed Dec 6 21:31:39 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Dec 2023 21:31:39 GMT Subject: RFR: 8301302: Platform preferences API [v43] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <-NpVMa-MsJG4gBAoJcu5nZoXVDYd47LzZsjZYV7_GV8=.ca4540f9-0a50-4743-9bd0-f81ceaadbd4b@github.com> On Wed, 6 Dec 2023 20:38:46 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > swap message fields All looks good now, so once you address the problems Jose and Andy have reported, I'll approve it. ------------- PR Review: https://git.openjdk.org/jfx/pull/1014#pullrequestreview-1768650182 From mstrauss at openjdk.org Wed Dec 6 21:31:40 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Dec 2023 21:31:40 GMT Subject: RFR: 8301302: Platform preferences API [v43] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Dec 2023 20:38:46 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > swap message fields > Looks like it's sending changes for values that have not changed: > > Screenshot 2023-12-06 at 11 30 04 > To reproduce on macOS 13.5.2: change System Settings -> Appearance -> Accent Color from green to yellow. > > I don't expect `macOS.NSColor.alternatingContentBackgroundColors=[0xffffffff, 0xf4f5f5ff]` to be sent because it has not changed. Turns out that this was a bug in the test application. It didn't print the actual content of the change notification, but did its own comparison of the entire map. I've updated the test application so that it prints exactly what's in the notification. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1843719549 From kcr at openjdk.org Wed Dec 6 21:42:20 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Dec 2023 21:42:20 GMT Subject: RFR: 8301302: Platform preferences API [v42] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Dec 2023 21:36:00 GMT, Michael Strau? wrote: > > * invert colors > > * increase contrast > > * display contrast (this seems to affect display's gamma, so probably not) > > These options are more like a post-processing effect of macOS, they don't affect the actual values of system colors. You'll notice that when "invert colors" is selected, the JavaFX window actually changes colors (without any change in how we render the window). > > I think we shouldn't include those options at the moment, and see whether anyone really needs this info in the future. I agree. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1843731471 From mstrauss at openjdk.org Wed Dec 6 21:42:20 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Dec 2023 21:42:20 GMT Subject: RFR: 8301302: Platform preferences API [v42] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Dec 2023 19:59:19 GMT, Andy Goryachev wrote: > macOS again, System Settings -> Accessibility -> Display > > should an update be sent when changing > > * invert colors > * increase contrast > * display contrast (this seems to affect display's gamma, so probably not) > These options are more like a post-processing effect of macOS, they don't affect the actual values of system colors. You'll notice that when "invert colors" is selected, the JavaFX window actually changes colors (without any change in how we render the window). I think we shouldn't include those options at the moment, and see whether anyone really needs this info in the future. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1843728227 From angorya at openjdk.org Wed Dec 6 21:47:25 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Dec 2023 21:47:25 GMT Subject: RFR: 8301302: Platform preferences API [v44] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Dec 2023 21:31:36 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fixed bug in test application minor: it's impossible to see the actual values for arrays: ` macOS.NSColor.alternatingContentBackgroundColors = [Ljavafx.scene.paint.Color;@55c22d31` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1843739012 From angorya at openjdk.org Wed Dec 6 21:52:20 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Dec 2023 21:52:20 GMT Subject: RFR: 8301302: Platform preferences API [v44] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Dec 2023 21:31:36 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fixed bug in test application The value does indeed change: macOS.NSColor.alternatingContentBackgroundColors = [0x1e1e1eff,0xffffff0c] macOS.NSColor.alternatingContentBackgroundColors = [0xffffffff,0xf4f5f5ff] private String f(Object x) { if (x == null) { return ""; } if (x.getClass().isArray()) { int sz = Array.getLength(x); StringBuilder sb = new StringBuilder(); sb.append("["); for (int i = 0; i < sz; i++) { if (i > 0) { sb.append(','); } sb.append(Array.get(x, i)); } sb.append("]"); return sb.toString(); } return x.toString(); } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1843744109 From mstrauss at openjdk.org Thu Dec 7 00:44:39 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 7 Dec 2023 00:44:39 GMT Subject: RFR: 8301302: Platform preferences API [v45] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - format arrays in test application, indicate added/removed prefs - fixed HighContrastScheme ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/515395b2..eac1d82f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=44 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=43-44 Stats: 168 lines in 3 files changed: 103 ins; 51 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Thu Dec 7 00:52:19 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 7 Dec 2023 00:52:19 GMT Subject: RFR: 8301302: Platform preferences API [v42] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Dec 2023 19:46:50 GMT, Jose Pereda wrote: > So I guess we'll need to review this `HighContrastScheme` enum, and see why `HighContrastScheme::fromThemeName` is not used. At some point, the call to `HighContrastScheme::fromThemeName` was lost. I've added it back in and discovered an additional problem with the existing implementation: The high-contrast scheme name that we get from the OS is always localized, independent of the JVM locale. Originally, the implementation matched the scheme name to a list of well-known localized scheme names, but only tested the names for the current JVM locale. Since there's no easy way to determine the OS locale, I've changed the implementation such that we now try to match the scheme name to _all_ known localized names. I've tested this with different OS/JVM locales, and it seems to work. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1843952106 From mstrauss at openjdk.org Thu Dec 7 00:52:19 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 7 Dec 2023 00:52:19 GMT Subject: RFR: 8301302: Platform preferences API [v44] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Dec 2023 21:44:26 GMT, Andy Goryachev wrote: > minor: it's impossible to see the actual values for arrays: > > ` macOS.NSColor.alternatingContentBackgroundColors = [Ljavafx.scene.paint.Color;@55c22d31` I added formatting for arrays. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1843953447 From mstrauss at openjdk.org Thu Dec 7 01:05:44 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 7 Dec 2023 01:05:44 GMT Subject: RFR: 8301302: Platform preferences API [v46] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: renamed Windows.SPI.HighContrastOn to Windows.SPI.HighContrast ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/eac1d82f..efdab27b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=45 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=44-45 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From angorya at openjdk.org Thu Dec 7 01:05:47 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 7 Dec 2023 01:05:47 GMT Subject: RFR: 8301302: Platform preferences API [v45] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 7 Dec 2023 00:44:39 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - format arrays in test application, indicate added/removed prefs > - fixed HighContrastScheme macOS looks good, thank you. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1014#pullrequestreview-1768916263 From mstrauss at openjdk.org Thu Dec 7 01:05:47 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 7 Dec 2023 01:05:47 GMT Subject: RFR: 8301302: Platform preferences API [v42] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <3F-MmPSdhEC5rbSIYWsJNATxt-6XZ9J6wlghEYgR-no=.43a775b5-79c3-4ded-a488-bb2227b5d227@github.com> On Wed, 6 Dec 2023 19:46:50 GMT, Jose Pereda wrote: > Note I get the preference `Windows.SPI.HighContrastOn`, which is not listed in the javadoc of `javafx.application.Platform.Preferences`, but I don't get these two preferences which are listed: > > ``` > Windows.SPI.HighContrast > Windows.SPI.HighContrastColorScheme > ``` The javadoc for `Platform.Preferences` indeed says `Windows.SPI.HighContrast`, while the implementation says `Windows.SPI.HighContrastOn`. I've changed the implementation to match the spec. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1843963386 From nlisker at openjdk.org Thu Dec 7 08:49:33 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 7 Dec 2023 08:49:33 GMT Subject: RFR: 8301302: Platform preferences API [v46] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 7 Dec 2023 01:05:44 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > renamed Windows.SPI.HighContrastOn to Windows.SPI.HighContrast There are classes such as `PlatformPreferences`, `PreferenceProperties`, and `ColorSchemeProperty` that are effectively singletons. Does it makes sense to just write them in a singleton pattern to avoid misuse? modules/javafx.graphics/src/main/java/com/sun/javafx/application/WindowsHighContrastScheme.java line 74: > 72: if (themeName == null) { > 73: return null; > 74: } This method is called only from `PlatformImpl` that already does the `null` check on the the string. In general, `null` checks should be done on the "outer most layer" and then all the inner layers can rely on the value being non-null. Is this method expected to be called from other places as well? If not, the method can be made package visible. modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 79: > 77: > 78: private final List invalidationListeners = new CopyOnWriteArrayList<>(); > 79: private final List> mapChangeListeners = new CopyOnWriteArrayList<>(); Can these be modified concurrently? What is the need for `CopyOnWriteArrayList`? modules/javafx.graphics/src/main/java/javafx/application/ColorScheme.java line 35: > 33: * @since 22 > 34: */ > 35: public enum ColorScheme { Can there be future additions to this enum, or is its purpose to be limited to the current choices? modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 1: > 1: /* I wonder if it's worth specifying the corresponding properties in JavaFX that match the ones in this class. For example, that the background property is used for `Region#backgroundProperty()`, and the foreground color is used for `Shape#fillProperty()` (or however `TextField` colors its text). modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 37: > 35: import javafx.scene.input.KeyCode; > 36: import javafx.scene.paint.Color; > 37: import javafx.scene.paint.Paint; Unused import. modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 474: > 472: *

> 473: * The following preferences are potentially available on the specified platforms: > 474: * Long tables can benefit from alternating colored rows. This can be achieved with `
` I think. modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 572: > 570: * @since 22 > 571: */ > 572: public interface Preferences extends ObservableMap { Note that this will be the first case where a public API implementation of `ObservableMap` is not for a general use type, but for a specific use case. All previous implementations are: `MapBinding, MapExpression, MapProperty, MapPropertyBase, ReadOnlyMapProperty, ReadOnlyMapPropertyBase, ReadOnlyMapWrapper, SimpleMapProperty`, and all are from the `base` module. This might be fine, but consider composition here. @kevinrushforth what do you think? modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 587: > 585: > 586: /** > 587: * The color used for background regions. Maybe "The color used for background **of** regions"? modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 589: > 587: * The color used for background regions. > 588: *

> 589: * If the platform does not report a background color, this property defaults to {@code Color.WHITE}. Is there value in writing this sentence on every property if they specify the `@defaultValue`? modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 604: > 602: * > 603: * @return the {@code foregroundColor} property > 604: * @defaultValue {@code Color.BLACK} Is `BLACK` a good default? From what I remember, because some devices have a difficulty with pure black, some dark gray color is used instead. modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 611: > 609: > 610: /** > 611: * The accent color. I think that this needs to explanation on what the accent color is. ------------- PR Review: https://git.openjdk.org/jfx/pull/1014#pullrequestreview-1769250088 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1418411093 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1418434560 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1418521512 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1418571391 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1418470429 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1418495453 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1418489681 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1418540211 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1418532876 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1418584560 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1418528568 From nlisker at gmail.com Thu Dec 7 09:46:46 2023 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 7 Dec 2023 11:46:46 +0200 Subject: Reflective discovery of styleable properties In-Reply-To: <0b448c30-712b-05ba-27f8-695785430fe0@gmail.com> References: <3cfd7806-45c1-1d52-2f78-c0ab1c5076cf@gmail.com> <0b448c30-712b-05ba-27f8-695785430fe0@gmail.com> Message-ID: > > I also like this route, perhaps slightly more, depending on how far this > can be taken > Yes, how far is the initial question I had when initially proposing the alternative Andy asked for. A few points: @Styleable(name = "-fx-label-padding", defaultValue = "(0, 0, 0, 0)") ... The required converter can be derived from the generic type (Insets -> > InsetsConverter), or specified (converter = InsetsConverter.class). Specifying the defaultValue in the annotation duplicates the one in the docs. This is minor, but we should keep it to one place. Specifying the converter is an implementation detail, so I don't think this will work well with a documented annotation. Maybe we shouldn't show the annotation then and specify the property name in the docs instead. The `isSettable` method is always the same boilerplate (and if not, you can > use the old way). > I noticed this too. Maybe this can be fixed at the class rather than at the processor. To convert a regular property into a styleable does require somewhat more > magic > We need to be careful with how much load we put on the annotation processor or on reflection. I'm not sure if we can replace the whole CSSMetadaData cleanly. I see that it has quite a lot of configuration. On Wed, Dec 6, 2023 at 6:41?PM John Hendrikx wrote: > You mean using an annotation processor? > > These can actually only create new types; modifying an existing one like > Lombok is doing is illegal (the original source code with Lombok > annotations is not plain Java anymore, hence an IDE plugin is required for > IDE's to understand it). > > Still, a lot is possible. I really like RecordBuilder ( > https://github.com/Randgalt/record-builder) -- it provide builders for > records (in a seperate type named `Builder`) and if your record > implements `Builder.With`, you even get wither methods courtesy > of the default methods on the generated interface > `Builder.With`. > > --John > On 06/12/2023 14:42, Thiago Milczarek Say?o wrote: > > Hi, > > Maybe it could generate the boilerplate like Lombok does? > So it has the benefits of eliminating error-prone boilerplate code and the > benefits of not having the cost of reflection at runtime. > > -- Thiago. > > > Em qua., 6 de dez. de 2023 ?s 10:28, John Hendrikx < > john.hendrikx at gmail.com> escreveu: > >> I also like this route, perhaps slightly more, depending on how far this >> can be taken: >> >> Disclaimer: I dislike the CSSMetaData and special property subclass a lot >> -- it's a major concession to make properties work with the CSS system that >> brings a lot of boilerplate that is mostly unnecessary. >> >> If you go the route of an annotation, we could offer to do everything via >> the annotation so a regular property can be converted to styleable by >> annotating it. The property would then have to specify the name >> ("-fx-label-padding") and the default value (which can be a string that is >> parseable via the existing CSS parser). >> >> In other words: >> >> @Styleable(name = "-fx-label-padding", defaultValue = "(0, 0, 0, 0)") >> public final ReadOnlyObjectProperty labelPaddingProperty() { ... >> } >> The rest the scanner can figure out (it could even figure out a default >> name). The `isSettable` method is always the same boilerplate (and if not, >> you can use the old way). The required converter can be derived from the >> generic type (Insets -> InsetsConverter), or specified (converter = >> InsetsConverter.class). >> >> To convert a regular property into a styleable does require somewhat more >> magic (the CSS system would have to wrap it, or otherwise track them) but >> that's all hidden. It gets rid of the StyleableProperty uglyness and the >> need for users to create those, and puts the "extra" CSSMetaData >> information a styleable property needs firmly where it belongs (in an >> annotation). >> >> --John >> >> On 06/12/2023 11:37, Nir Lisker wrote: >> >> I thought about the option of reflection, but I opted to propose >> annotations instead. The following is my reasoning. >> >> Firstly, reflection is very magic-y. The author of the class has no >> indication of what side effects happen due to the code they write, the >> output (css handling in this case) comes out of nowhere from their >> perspective. As with other reflection cases, it is a "pull" rather than >> "push" approach - you don't write what should happen, you let someone else >> decide that. For writers of skin/control classes, this means that they need >> to know exactly what constitutes a hook for the reflection mechanism, or >> face surprises. There is no compile time check that tells you whether you >> have declared your styleable property properly or not (without an external >> ad-hoc checker). >> We do this somewhat with properties - any method of the form >> "...property()" gets special treatment, but this is for the docs. I don't >> think we have code that depends on this other than in tests. >> >> Secondly, the proposed mechanism depends on the runtime type, not the >> declared type. As a user, I see no indication in the API whether a property >> is styleable or not. This is also (what I would consider) a problem with >> the current state. When I thought about using reflection to solve this, I >> at least thought to specify the declared type of the property as styleable, >> like StyleableBooleanProperty instead of BooleanProperty (restricting the >> returned type is backwards compatible). A downside of this is that it gives >> access to the methods of StyleableProperty, which are not useful for the >> user, I think, but maybe someone has a use for them. >> >> Thirdly, maybe I want to declare a styleable property not to be used >> automatically. I can't think off the top of my head when I would want to do >> that, but I'm also not a heavy css user. Are we sure that just initializing >> a property with a styleable runtime type should *always* be caught by this >> process? >> >> To compare, annotations have the following benefits: >> >> Firstly, they are declarative, which means no surprises for the class >> author (WYSIWYG). This also allows more flexibility/control over which >> properties get special treatment via an opt-in mechanism. >> >> Secondly, They can also be displayed in the JavaDocs (via @Documented) >> with their assigned values. For example, the padding property of Region can >> be annotated with @Styleable(property="-fx-padding"), informing the user >> both that this value can be set by css, and how to do it. Interestingly, >> the annotation doesn't need to be public API to be displayed, so we are not >> bound by contracts. >> >> In terms of similarities: >> >> In both the reflection and the annotation proposals, the steps are: >> 1. Create styleable properties. >> 2. That's it. >> It's just that step 1 also adds an annotation to the creation of the >> property (which was/is a 2-step process anyway, declaring the property and >> its css metadata). >> >> Annotations also require a processor to read the data from their values >> and target (the field/method). This is a bit of work, but >> Michael's CssMetaDataCache class is basically that - read the data from the >> class (via reflection or annotations) and store it in a map. The logic >> should be the same, just the method to obtain the data is different. Both, >> as a result, have the benefits of handling control/skin combinations (what >> I mentioned in the point "Usable both in controls and in skins (or other >> classes)"). >> >> The benefit of co-locating the property and its css metadata in the class >> itself also remains. >> >> >> To summarize, both approaches eliminate all the clutter of writing >> styleable properties (John, will you like to create styleable properties >> now? [1] :) ), both apply the flexibility of caching per class, both allow >> better structuring of the class, but they read the properties differently >> and have a different level of declarativness. >> >> [1] >> https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044010.html >> >> >> On Tue, Dec 5, 2023 at 11:21?PM Andy Goryachev >> wrote: >> >>> I like the idea. >>> >>> >>> >>> I wonder if it is possible to reduce the amount of boilerplate code? >>> For example, a CssMetaData can have a >>> >>> >>> >>> setGetter(Function> getter) >>> >>> >>> >>> method which supplies the property reference? This way >>> CssMetaData.isSettable(Node) and CssMetaData.getStyleableProperty(Node) can >>> be implemented in the base class (there are more complicated cases, so >>> perhaps setIsSettable(Predicate) would also be required). >>> >>> >>> >>> Example: >>> >>> >>> >>> CssMetaData.of("-fx-font", Font.getDefault(), (n) >>> -> n.font) >>> >>> >>> >>> Just a thought. What do you think? >>> >>> >>> >>> -andy >>> >>> >>> >>> >>> >>> *From: *openjfx-dev on behalf of Michael >>> Strau? >>> *Date: *Sunday, December 3, 2023 at 22:02 >>> *To: *openjfx-dev >>> *Subject: *Reflective discovery of styleable properties >>> >>> Following up the discussion around the CssMetaData API, I'd like to >>> chime in with yet another idea. To recap, here's Nir's summary of the >>> current API [0]: >>> >>> "Let's look at what implementation is required from a user who wants >>> to write their own styleable control: >>> 1. Create styleable properties. >>> 2. Create a list of these properties to be passed on. >>> 3. Create a public static method that returns the concatenation of >>> this list with the one of its parent. (This method happens to be >>> poorly documented, as mstr said.) >>> 4. Create a public non-static method that calls the static method in a >>> forced-override pattern because otherwise you will be calling the >>> wrong static method. (This method's docs seem to be just wrong because >>> you don't always want to delegate to Node's list.)" >>> >>> >>> I think this could reasonably be replaced with the following >>> implementation requirements: >>> 1. Create styleable properties. >>> 2. That's it. >>> >>> Let's look at what we're actually trying to do: create a list of >>> CSS-styleable property metadata of a class. But we can easily do that >>> without all of the boilerplate code. >>> >>> When ?Node.getCssMetaData()` is invoked, all public methods of the >>> class are reflectively enumerated, and metadata is retrieved from >>> `Property` and `StyleableProperty` getters. This is a price that's >>> only paid once for any particular class (i.e. not for every instance). >>> The resulting metadata list is cached and reused for all instances of >>> that particular class. >>> >>> As a further optimization, metadata lists are also cached and >>> deduplicated for Control/Skin combinations (currently every Control >>> instance has its own copy of the metadata list). >>> >>> Another benefit of this approach is that the CssMetaData can now be >>> co-located with the property implementation, and not be kept around in >>> other parts of the source code file. Here's how that looks like when a >>> new "myValue" property is added to MyClass: >>> >>> StyleableDoubleProperty myValue = >>> new SimpleStyleableDoubleProperty(this, "myValue") { >>> >>> static final CssMetaData METADATA = >>> new CssMetaData( >>> "-fx-my-value", >>> SizeConverter.getInstance(), >>> USE_COMPUTED_SIZE) { >>> @Override >>> public boolean isSettable(MyClass node) { >>> return !node.myValue.isBound(); >>> } >>> >>> @Override >>> public StyleableProperty getStyleableProperty( >>> MyClass node) { >>> return node.myValue; >>> } >>> }; >>> >>> @Override >>> public CssMetaData getCssMetaData() { >>> return METADATA; >>> } >>> }; >>> >>> public final DoubleProperty myValueProperty() { >>> return myValue; >>> } >>> >>> It is not required to override the `getCssMetaData()` method, nor is >>> it required to redeclare a new static `getClassCssMetaData()` method. >>> It is also not required to manually keep the list of styleable >>> properties in sync with the list of CSS metadata. >>> >>> I've prototyped this concept for the `Node`, `Region` and `Control` >>> classes [1]. >>> >>> [0] >>> https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044046.html >>> [1] https://github.com/openjdk/jfx/pull/1299 >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Thu Dec 7 09:53:56 2023 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 7 Dec 2023 11:53:56 +0200 Subject: [External] : Re: Reflective discovery of styleable properties In-Reply-To: References: Message-ID: > > - I would recommend against the scanner figuring out the property name: > the property > names are codified by the CSS reference which serves as a > normative document in this case > I think that the CSS reference should be generated from the source code, which is something the annotation processor can do. - isSettable() logic might be more complex than (prop == null && > !(prop.isBound)), see Node.translateXProperty. How would that work with > annotations? >From what John said, you can fall back to the CSSMetaData way if the defaults are not good for you. On Wed, Dec 6, 2023 at 6:21?PM Andy Goryachev wrote: > I also like this idea very much. Still needs a reflective scanner, but > it's far more easier to understand and use. > > > > A couple of comments/questions: > > > > - I would recommend against the scanner figuring out the property name: > the property names are codified by the CSS reference which serves as a > normative document in this case > > > > - isSettable() logic might be more complex than (prop == null && > !(prop.isBound)), see Node.translateXProperty. How would that work with > annotations? > > > > What do you think? > > > > -andy > > > > > > > > *From: *Nir Lisker > *Date: *Wednesday, December 6, 2023 at 02:37 > *To: *Andy Goryachev > *Cc: *Michael Strau? , openjfx-dev < > openjfx-dev at openjdk.org> > *Subject: *[External] : Re: Reflective discovery of styleable properties > > I thought about the option of reflection, but I opted to propose > annotations instead. The following is my reasoning. > > > > Firstly, reflection is very magic-y. The author of the class has no > indication of what side effects happen due to the code they write, the > output (css handling in this case) comes out of nowhere from their > perspective. As with other reflection cases, it is a "pull" rather than > "push" approach - you don't write what should happen, you let someone else > decide that. For writers of skin/control classes, this means that they need > to know exactly what constitutes a hook for the reflection mechanism, or > face surprises. There is no compile time check that tells you whether you > have declared your styleable property properly or not (without an external > ad-hoc checker). > > We do this somewhat with properties - any method of the form > "...property()" gets special treatment, but this is for the docs. I don't > think we have code that depends on this other than in tests. > > > > Secondly, the proposed mechanism depends on the runtime type, not the > declared type. As a user, I see no indication in the API whether a property > is styleable or not. This is also (what I would consider) a problem with > the current state. When I thought about using reflection to solve this, I > at least thought to specify the declared type of the property as styleable, > like StyleableBooleanProperty instead of BooleanProperty (restricting the > returned type is backwards compatible). A downside of this is that it gives > access to the methods of StyleableProperty, which are not useful for the > user, I think, but maybe someone has a use for them. > > > > Thirdly, maybe I want to declare a styleable property not to be used > automatically. I can't think off the top of my head when I would want to do > that, but I'm also not a heavy css user. Are we sure that just initializing > a property with a styleable runtime type should *always* be caught by this > process? > > > > To compare, annotations have the following benefits: > > > > Firstly, they are declarative, which means no surprises for the class > author (WYSIWYG). This also allows more flexibility/control over which > properties get special treatment via an opt-in mechanism. > > > > Secondly, They can also be displayed in the JavaDocs (via @Documented) > with their assigned values. For example, the padding property of Region can > be annotated with @Styleable(property="-fx-padding"), informing the user > both that this value can be set by css, and how to do it. Interestingly, > the annotation doesn't need to be public API to be displayed, so we are not > bound by contracts. > > > > In terms of similarities: > > > > In both the reflection and the annotation proposals, the steps are: > > 1. Create styleable properties. > 2. That's it. > > It's just that step 1 also adds an annotation to the creation of the > property (which was/is a 2-step process anyway, declaring the property and > its css metadata). > > > > Annotations also require a processor to read the data from their values > and target (the field/method). This is a bit of work, but > Michael's CssMetaDataCache class is basically that - read the data from the > class (via reflection or annotations) and store it in a map. The logic > should be the same, just the method to obtain the data is different. Both, > as a result, have the benefits of handling control/skin combinations (what > I mentioned in the point "Usable both in controls and in skins (or other > classes)"). > > > > The benefit of co-locating the property and its css metadata in the class > itself also remains. > > > > > > To summarize, both approaches eliminate all the clutter of writing > styleable properties (John, will you like to create styleable properties > now? [1] :) ), both apply the flexibility of caching per class, both allow > better structuring of the class, but they read the properties differently > and have a different level of declarativness. > > > > [1] > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044010.html > > > > > > On Tue, Dec 5, 2023 at 11:21?PM Andy Goryachev > wrote: > > I like the idea. > > > > I wonder if it is possible to reduce the amount of boilerplate code? For > example, a CssMetaData can have a > > > > setGetter(Function> getter) > > > > method which supplies the property reference? This way > CssMetaData.isSettable(Node) and CssMetaData.getStyleableProperty(Node) can > be implemented in the base class (there are more complicated cases, so > perhaps setIsSettable(Predicate) would also be required). > > > > Example: > > > > CssMetaData.of("-fx-font", Font.getDefault(), (n) -> > n.font) > > > > Just a thought. What do you think? > > > > -andy > > > > > > *From: *openjfx-dev on behalf of Michael > Strau? > *Date: *Sunday, December 3, 2023 at 22:02 > *To: *openjfx-dev > *Subject: *Reflective discovery of styleable properties > > Following up the discussion around the CssMetaData API, I'd like to > chime in with yet another idea. To recap, here's Nir's summary of the > current API [0]: > > "Let's look at what implementation is required from a user who wants > to write their own styleable control: > 1. Create styleable properties. > 2. Create a list of these properties to be passed on. > 3. Create a public static method that returns the concatenation of > this list with the one of its parent. (This method happens to be > poorly documented, as mstr said.) > 4. Create a public non-static method that calls the static method in a > forced-override pattern because otherwise you will be calling the > wrong static method. (This method's docs seem to be just wrong because > you don't always want to delegate to Node's list.)" > > > I think this could reasonably be replaced with the following > implementation requirements: > 1. Create styleable properties. > 2. That's it. > > Let's look at what we're actually trying to do: create a list of > CSS-styleable property metadata of a class. But we can easily do that > without all of the boilerplate code. > > When ?Node.getCssMetaData()` is invoked, all public methods of the > class are reflectively enumerated, and metadata is retrieved from > `Property` and `StyleableProperty` getters. This is a price that's > only paid once for any particular class (i.e. not for every instance). > The resulting metadata list is cached and reused for all instances of > that particular class. > > As a further optimization, metadata lists are also cached and > deduplicated for Control/Skin combinations (currently every Control > instance has its own copy of the metadata list). > > Another benefit of this approach is that the CssMetaData can now be > co-located with the property implementation, and not be kept around in > other parts of the source code file. Here's how that looks like when a > new "myValue" property is added to MyClass: > > StyleableDoubleProperty myValue = > new SimpleStyleableDoubleProperty(this, "myValue") { > > static final CssMetaData METADATA = > new CssMetaData( > "-fx-my-value", > SizeConverter.getInstance(), > USE_COMPUTED_SIZE) { > @Override > public boolean isSettable(MyClass node) { > return !node.myValue.isBound(); > } > > @Override > public StyleableProperty getStyleableProperty( > MyClass node) { > return node.myValue; > } > }; > > @Override > public CssMetaData getCssMetaData() { > return METADATA; > } > }; > > public final DoubleProperty myValueProperty() { > return myValue; > } > > It is not required to override the `getCssMetaData()` method, nor is > it required to redeclare a new static `getClassCssMetaData()` method. > It is also not required to manually keep the list of styleable > properties in sync with the list of CSS metadata. > > I've prototyped this concept for the `Node`, `Region` and `Control` > classes [1]. > > [0] > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044046.html > [1] https://github.com/openjdk/jfx/pull/1299 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.vos at gluonhq.com Thu Dec 7 10:37:14 2023 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 7 Dec 2023 11:37:14 +0100 Subject: eclipse warnings In-Reply-To: References: <24f4a015-4093-496b-81a1-0d972f9bd686@oracle.com> Message-ID: That's a good question. I guess it's a compromise. >From a backport-point-of-view, 1 PR (hence 1 JBS issue) per file is ideal. But that is not realistic of course, as it would clutter the JBS issues and the github PR's. I think package-based PR's would be a good compromise. That would also make it feasible to review in depth. Note that I think it would be better to change the title from "Eclipse warnings" into "Coding enhancements". I don't think we want Eclipse to decide the coding approaches in OpenJFX, as we can have follow-up PR's then about "NetBeans warnings" or "IntelliJ warnings" :) - Johan On Wed, Dec 6, 2023 at 5:06?PM Andy Goryachev wrote: > Dear Johan: > > > > What would be your best recommendation to minimize the burden? Split into > small PRs on a per-module or per-package basis? > > > > Thanks, > > -andy > > > > > > > > *From: *openjfx-dev on behalf of Johan Vos > > *Date: *Monday, December 4, 2023 at 09:25 > *To: *Kevin Rushforth > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: eclipse warnings > > Also, these commits often affect many files at once (in scattered > locations), and that makes backports harder. > > > > - Johan > > > > On Mon, Dec 4, 2023 at 6:14?PM Kevin Rushforth > wrote: > > We did a few of these sort of cleanup fixes a year or so ago. > > In general, this sort of cleanup *might* be useful, but also causes some > code churn and takes review cycles to ensure that there is no unintentional > side effect. > > The last two might be OK cleanup tasks, but I wouldn't make them a high > priority. Worth noting is that a seemingly redundant null check or > instanceof check is not always a bad thing, so I wouldn't clean up all of > them. > > The first group is the more interesting one. In some cases a potential > null access can highlight actual bugs. However, I oppose any automated > solution for these, since adding a null check where you don't expect a null > (even if you IDE thinks it might be possible) can hide the root cause of a > problem. > > We aren't going to enforce these, though, so you'll likely need to > configure your IDE to be less picky. > > -- Kevin > > On 12/4/2023 8:34 AM, Andy Goryachev wrote: > > Dear colleagues: > > > > Imported the openjfx project into another workspace with a more stringent > error checking and discovered a few issues: > > > > - potential null pointer access: 295 > - unnecessary cast or instanceof: 190 > - redundant null check: 61 > > > > Do we want to clean these up? > > > > -andy > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Thu Dec 7 15:38:18 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 7 Dec 2023 15:38:18 +0000 Subject: [External] : Re: eclipse warnings In-Reply-To: References: <24f4a015-4093-496b-81a1-0d972f9bd686@oracle.com> Message-ID: Thank you, Johan. Just to clarify, the "eclipse" is used by the umbrella task https://bugs.openjdk.org/browse/JDK-8297300, the actual changes come under their own specific titles. Very low priority. -andy From: Johan Vos Date: Thursday, December 7, 2023 at 02:37 To: Andy Goryachev Cc: Kevin Rushforth , openjfx-dev at openjdk.org Subject: [External] : Re: eclipse warnings That's a good question. I guess it's a compromise. From a backport-point-of-view, 1 PR (hence 1 JBS issue) per file is ideal. But that is not realistic of course, as it would clutter the JBS issues and the github PR's. I think package-based PR's would be a good compromise. That would also make it feasible to review in depth. Note that I think it would be better to change the title from "Eclipse warnings" into "Coding enhancements". I don't think we want Eclipse to decide the coding approaches in OpenJFX, as we can have follow-up PR's then about "NetBeans warnings" or "IntelliJ warnings" :) - Johan On Wed, Dec 6, 2023 at 5:06?PM Andy Goryachev > wrote: Dear Johan: What would be your best recommendation to minimize the burden? Split into small PRs on a per-module or per-package basis? Thanks, -andy From: openjfx-dev > on behalf of Johan Vos > Date: Monday, December 4, 2023 at 09:25 To: Kevin Rushforth > Cc: openjfx-dev at openjdk.org > Subject: Re: eclipse warnings Also, these commits often affect many files at once (in scattered locations), and that makes backports harder. - Johan On Mon, Dec 4, 2023 at 6:14?PM Kevin Rushforth > wrote: We did a few of these sort of cleanup fixes a year or so ago. In general, this sort of cleanup *might* be useful, but also causes some code churn and takes review cycles to ensure that there is no unintentional side effect. The last two might be OK cleanup tasks, but I wouldn't make them a high priority. Worth noting is that a seemingly redundant null check or instanceof check is not always a bad thing, so I wouldn't clean up all of them. The first group is the more interesting one. In some cases a potential null access can highlight actual bugs. However, I oppose any automated solution for these, since adding a null check where you don't expect a null (even if you IDE thinks it might be possible) can hide the root cause of a problem. We aren't going to enforce these, though, so you'll likely need to configure your IDE to be less picky. -- Kevin On 12/4/2023 8:34 AM, Andy Goryachev wrote: Dear colleagues: Imported the openjfx project into another workspace with a more stringent error checking and discovered a few issues: * potential null pointer access: 295 * unnecessary cast or instanceof: 190 * redundant null check: 61 Do we want to clean these up? -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Thu Dec 7 15:48:23 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 7 Dec 2023 15:48:23 +0000 Subject: [External] : Re: Reflective discovery of styleable properties In-Reply-To: References: Message-ID: > I think that the CSS reference should be generated from the source code, which is something the annotation processor can do. Surely, you don't suggest we should change the CSS ref? https://openjfx.io/javadoc/21/javafx.graphics/javafx/scene/doc-files/cssref.html I subscribe to a school of thought that requires specifications written by humans for humans. The CSS reference is, in my opinion, an authoritative source, so I would be against developing any tooling that generates it from the source code. -andy From: Nir Lisker Date: Thursday, December 7, 2023 at 01:54 To: Andy Goryachev Cc: Michael Strau? , openjfx-dev Subject: Re: [External] : Re: Reflective discovery of styleable properties - I would recommend against the scanner figuring out the property name: the property > names are codified by the CSS reference which serves as a normative document in this case I think that the CSS reference should be generated from the source code, which is something the annotation processor can do. - isSettable() logic might be more complex than (prop == null && !(prop.isBound)), see Node.translateXProperty. How would that work with annotations? From what John said, you can fall back to the CSSMetaData way if the defaults are not good for you. On Wed, Dec 6, 2023 at 6:21?PM Andy Goryachev > wrote: I also like this idea very much. Still needs a reflective scanner, but it's far more easier to understand and use. A couple of comments/questions: - I would recommend against the scanner figuring out the property name: the property names are codified by the CSS reference which serves as a normative document in this case - isSettable() logic might be more complex than (prop == null && !(prop.isBound)), see Node.translateXProperty. How would that work with annotations? What do you think? -andy From: Nir Lisker > Date: Wednesday, December 6, 2023 at 02:37 To: Andy Goryachev > Cc: Michael Strau? >, openjfx-dev > Subject: [External] : Re: Reflective discovery of styleable properties I thought about the option of reflection, but I opted to propose annotations instead. The following is my reasoning. Firstly, reflection is very magic-y. The author of the class has no indication of what side effects happen due to the code they write, the output (css handling in this case) comes out of nowhere from their perspective. As with other reflection cases, it is a "pull" rather than "push" approach - you don't write what should happen, you let someone else decide that. For writers of skin/control classes, this means that they need to know exactly what constitutes a hook for the reflection mechanism, or face surprises. There is no compile time check that tells you whether you have declared your styleable property properly or not (without an external ad-hoc checker). We do this somewhat with properties - any method of the form "...property()" gets special treatment, but this is for the docs. I don't think we have code that depends on this other than in tests. Secondly, the proposed mechanism depends on the runtime type, not the declared type. As a user, I see no indication in the API whether a property is styleable or not. This is also (what I would consider) a problem with the current state. When I thought about using reflection to solve this, I at least thought to specify the declared type of the property as styleable, like StyleableBooleanProperty instead of BooleanProperty (restricting the returned type is backwards compatible). A downside of this is that it gives access to the methods of StyleableProperty, which are not useful for the user, I think, but maybe someone has a use for them. Thirdly, maybe I want to declare a styleable property not to be used automatically. I can't think off the top of my head when I would want to do that, but I'm also not a heavy css user. Are we sure that just initializing a property with a styleable runtime type should *always* be caught by this process? To compare, annotations have the following benefits: Firstly, they are declarative, which means no surprises for the class author (WYSIWYG). This also allows more flexibility/control over which properties get special treatment via an opt-in mechanism. Secondly, They can also be displayed in the JavaDocs (via @Documented) with their assigned values. For example, the padding property of Region can be annotated with @Styleable(property="-fx-padding"), informing the user both that this value can be set by css, and how to do it. Interestingly, the annotation doesn't need to be public API to be displayed, so we are not bound by contracts. In terms of similarities: In both the reflection and the annotation proposals, the steps are: 1. Create styleable properties. 2. That's it. It's just that step 1 also adds an annotation to the creation of the property (which was/is a 2-step process anyway, declaring the property and its css metadata). Annotations also require a processor to read the data from their values and target (the field/method). This is a bit of work, but Michael's CssMetaDataCache class is basically that - read the data from the class (via reflection or annotations) and store it in a map. The logic should be the same, just the method to obtain the data is different. Both, as a result, have the benefits of handling control/skin combinations (what I mentioned in the point "Usable both in controls and in skins (or other classes)"). The benefit of co-locating the property and its css metadata in the class itself also remains. To summarize, both approaches eliminate all the clutter of writing styleable properties (John, will you like to create styleable properties now? [1] :) ), both apply the flexibility of caching per class, both allow better structuring of the class, but they read the properties differently and have a different level of declarativness. [1] https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044010.html On Tue, Dec 5, 2023 at 11:21?PM Andy Goryachev > wrote: I like the idea. I wonder if it is possible to reduce the amount of boilerplate code? For example, a CssMetaData can have a setGetter(Function> getter) method which supplies the property reference? This way CssMetaData.isSettable(Node) and CssMetaData.getStyleableProperty(Node) can be implemented in the base class (there are more complicated cases, so perhaps setIsSettable(Predicate) would also be required). Example: CssMetaData.of("-fx-font", Font.getDefault(), (n) -> n.font) Just a thought. What do you think? -andy From: openjfx-dev > on behalf of Michael Strau? > Date: Sunday, December 3, 2023 at 22:02 To: openjfx-dev > Subject: Reflective discovery of styleable properties Following up the discussion around the CssMetaData API, I'd like to chime in with yet another idea. To recap, here's Nir's summary of the current API [0]: "Let's look at what implementation is required from a user who wants to write their own styleable control: 1. Create styleable properties. 2. Create a list of these properties to be passed on. 3. Create a public static method that returns the concatenation of this list with the one of its parent. (This method happens to be poorly documented, as mstr said.) 4. Create a public non-static method that calls the static method in a forced-override pattern because otherwise you will be calling the wrong static method. (This method's docs seem to be just wrong because you don't always want to delegate to Node's list.)" I think this could reasonably be replaced with the following implementation requirements: 1. Create styleable properties. 2. That's it. Let's look at what we're actually trying to do: create a list of CSS-styleable property metadata of a class. But we can easily do that without all of the boilerplate code. When ?Node.getCssMetaData()` is invoked, all public methods of the class are reflectively enumerated, and metadata is retrieved from `Property` and `StyleableProperty` getters. This is a price that's only paid once for any particular class (i.e. not for every instance). The resulting metadata list is cached and reused for all instances of that particular class. As a further optimization, metadata lists are also cached and deduplicated for Control/Skin combinations (currently every Control instance has its own copy of the metadata list). Another benefit of this approach is that the CssMetaData can now be co-located with the property implementation, and not be kept around in other parts of the source code file. Here's how that looks like when a new "myValue" property is added to MyClass: StyleableDoubleProperty myValue = new SimpleStyleableDoubleProperty(this, "myValue") { static final CssMetaData METADATA = new CssMetaData( "-fx-my-value", SizeConverter.getInstance(), USE_COMPUTED_SIZE) { @Override public boolean isSettable(MyClass node) { return !node.myValue.isBound(); } @Override public StyleableProperty getStyleableProperty( MyClass node) { return node.myValue; } }; @Override public CssMetaData getCssMetaData() { return METADATA; } }; public final DoubleProperty myValueProperty() { return myValue; } It is not required to override the `getCssMetaData()` method, nor is it required to redeclare a new static `getClassCssMetaData()` method. It is also not required to manually keep the list of styleable properties in sync with the list of CSS metadata. I've prototyped this concept for the `Node`, `Region` and `Control` classes [1]. [0] https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044046.html [1] https://github.com/openjdk/jfx/pull/1299 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Dec 7 15:58:26 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Dec 2023 15:58:26 GMT Subject: RFR: 8301302: Platform preferences API [v46] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <3LVyF0kJ4c6Z8OaJwiaMup82lAgyRvHmHNscYx0Pwok=.1268df6d-faf1-4358-bf18-3bc3882c96b0@github.com> On Thu, 7 Dec 2023 01:05:44 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > renamed Windows.SPI.HighContrastOn to Windows.SPI.HighContrast With the latest set of changes, this looks good to me. I left a couple questions / minor comments (mostly for follow-up) and answered a couple of Nir's questions. modules/javafx.graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java line 779: > 777: if (highContrastScheme == null) { > 778: return; > 779: } Minor: You could eliminate the null check if you defined a new "NONE" or "UNKNOWN" enum and restored the (no-op) `default:` on line 837. It's fine the way you have it, if you prefer. modules/javafx.graphics/src/main/java/com/sun/javafx/application/WindowsHighContrastScheme.java line 80: > 78: // since we might be running on a JVM with a locale that is different from the OS. > 79: for (WindowsHighContrastScheme item : values()) { > 80: for (ResourceBundle resourceBundle : resourceBundles) { Depending on how often this is called, might it be worth caching a `Map` whose keys are the OS theme names and values are the corresponding enum values? This could be a follow-up enhancement if it were deemed important enough, but maybe it doesn't matter. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1014#pullrequestreview-1770417179 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419138607 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419153011 From angorya at openjdk.org Thu Dec 7 15:58:28 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 7 Dec 2023 15:58:28 GMT Subject: RFR: 8301302: Platform preferences API [v46] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 7 Dec 2023 01:05:44 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > renamed Windows.SPI.HighContrastOn to Windows.SPI.HighContrast Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1014#pullrequestreview-1770503187 From kcr at openjdk.org Thu Dec 7 15:58:34 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Dec 2023 15:58:34 GMT Subject: RFR: 8301302: Platform preferences API [v46] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 7 Dec 2023 07:57:01 GMT, Nir Lisker wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> renamed Windows.SPI.HighContrastOn to Windows.SPI.HighContrast > > modules/javafx.graphics/src/main/java/javafx/application/ColorScheme.java line 35: > >> 33: * @since 22 >> 34: */ >> 35: public enum ColorScheme { > > Can there be future additions to this enum, or is its purpose to be limited to the current choices? I suspect this is limited to the current choices, but it's a good question. > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 1: > >> 1: /* > > I wonder if it's worth specifying the corresponding properties in JavaFX that match the ones in this class. For example, that the background property is used for `Region#backgroundProperty()`, and the foreground color is used for `Shape#fillProperty()` (or however `TextField` colors its text). With the exception of the high-contrast theme on Windows, JavaFX doesn't make any use of these platform-specific properties. It's up to the application to do that. > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 474: > >> 472: *

>> 473: * The following preferences are potentially available on the specified platforms: >> 474: *

> > Long tables can benefit from alternating colored rows. This can be achieved with `
` I think. That might be a good enhancement for other tables as well (GraphicsContext comes to mind). I would recommend this as a follow-up. > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 572: > >> 570: * @since 22 >> 571: */ >> 572: public interface Preferences extends ObservableMap { > > Note that this will be the first case where a public API implementation of `ObservableMap` is not for a general use type, but for a specific use case. All previous implementations are: > `MapBinding, MapExpression, MapProperty, MapPropertyBase, ReadOnlyMapProperty, ReadOnlyMapPropertyBase, ReadOnlyMapWrapper, SimpleMapProperty`, and all are from the `base` module. > > This might be fine, but consider composition here. > > @kevinrushforth what do you think? I think this is OK. Given what it is being used for, I'm satisfied with the API. One thing we could consider is an `@implNote` indicating that applications are not expected to implement this. This could be done as a follow-up. > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 604: > >> 602: * >> 603: * @return the {@code foregroundColor} property >> 604: * @defaultValue {@code Color.BLACK} > > Is `BLACK` a good default? From what I remember, because some devices have a difficulty with pure black, some dark gray color is used instead. I would expect this to be one of the properties that is set on all platforms anyway, but if not, I think this `BLACK` is a reasonable default. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419168545 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419174768 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419167654 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419166082 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419177332 From kevin.rushforth at oracle.com Thu Dec 7 16:07:23 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 7 Dec 2023 08:07:23 -0800 Subject: [External] : Re: Reflective discovery of styleable properties In-Reply-To: References: Message-ID: <95597fae-5115-452b-ad37-c9b8dc649304@oracle.com> I haven't looked at this proposal yet, but there are some interesting ideas here worth further discussion. I just wanted to weigh in on the cssref piece. As Andy indicated, cssref.html is the normative specification for JavaFX CSS properties. And no, it can't be (fully) auto-generated. The only way I could imagine tooling being involved is to auto-generate the individual property tables for including in the html somehow (which would need some sort of javadoc-inspired facility to add comments in the table, etc). And while an interesting concept, it would likely be a rather large effort for relatively little gain. -- Kevin On 12/7/2023 7:48 AM, Andy Goryachev wrote: > > > I think that the CSS reference should be generated from the source > code, which is something the annotation processor can do. > > Surely, you don't suggest we should change the CSS ref? > > https://openjfx.io/javadoc/21/javafx.graphics/javafx/scene/doc-files/cssref.html > > I subscribe to a school of thought that requires specifications > written by humans for humans.? The CSS reference is, in my opinion, an > authoritative source, so I would be against developing any tooling > that generates it from the source code. > > -andy > > *From: *Nir Lisker > *Date: *Thursday, December 7, 2023 at 01:54 > *To: *Andy Goryachev > *Cc: *Michael Strau? , openjfx-dev > > *Subject: *Re: [External] : Re: Reflective discovery of styleable > properties > > ?- I would recommend against the scanner figuring out the property > name: the property > names are codified by the CSS reference which > serves as a normative document in this case > > I think that the CSS reference should be generated from the source > code, which is something the annotation processor can do. > > - isSettable() logic might be more complex than (prop == null && > !(prop.isBound)), see Node.translateXProperty. How would that work > with annotations? > > From what John said, you can fall back to the CSSMetaData way if the > defaults are not good for you. > > On Wed, Dec 6, 2023 at 6:21?PM Andy Goryachev > wrote: > > I also like this idea very much.? Still needs a reflective > scanner, but it's far more easier to understand and use. > > A couple of comments/questions: > > - I would recommend against the scanner figuring out the property > name: the property names are codified by the CSS reference which > serves as a normative document in this case > > - isSettable() logic might be more complex than (prop == null && > !(prop.isBound)), see Node.translateXProperty.? How would that > work with annotations? > > What do you think? > > -andy > > *From: *Nir Lisker > *Date: *Wednesday, December 6, 2023 at 02:37 > *To: *Andy Goryachev > *Cc: *Michael Strau? , openjfx-dev > > *Subject: *[External] : Re: Reflective discovery of styleable > properties > > I thought about the option of reflection, but I opted?to propose > annotations instead. The following is my reasoning. > > Firstly, reflection is very magic-y. The author of the class has > no indication of what side effects happen due to the code they > write, the output (css handling in this case) comes out of nowhere > from their perspective. As with other reflection cases, it is a > "pull" rather than "push" approach - you don't write what should > happen, you let someone else decide?that. For writers of > skin/control classes, this means that they need to know exactly > what constitutes?a hook for the reflection mechanism, or face > surprises. There is no compile time check that tells you whether > you have declared your styleable property properly or not (without > an external ad-hoc checker). > > We do this somewhat with properties - any method of the form > "...property()" gets special treatment, but this is for the docs. > I don't think we have code that depends on this other than in tests. > > Secondly, the proposed mechanism depends on the runtime type, not > the declared type. As a user, I see no indication in the API > whether a property is styleable or not. This is also (what I would > consider) a problem with the current state. When I thought about > using reflection to solve this, I at least thought to specify the > declared type of the property as styleable, like > StyleableBooleanProperty instead of BooleanProperty (restricting > the returned type is backwards compatible). A downside of this is > that it gives access to the methods of StyleableProperty, which > are not useful for the user, I think, but maybe someone has a use > for them. > > Thirdly, maybe I want to declare a styleable property?not to be > used automatically. I can't think off the top of my head when I > would want to do that, but I'm also not a heavy css user. Are we > sure that just initializing a property with a styleable runtime > type should *always* be caught by this process? > > To compare, annotations have the following benefits: > > Firstly, they are declarative, which means no surprises for the > class author (WYSIWYG). This also allows more flexibility/control > over which properties get special treatment via an opt-in mechanism. > > Secondly, They can also be displayed in the JavaDocs > (via?@Documented) with their assigned values. For example, the > padding property of Region can be annotated > with?@Styleable(property="-fx-padding"), informing the user both > that this value can be set by css, and how to do it. > Interestingly, the annotation doesn't need to be public API to be > displayed, so we are not bound by contracts. > > In terms of similarities: > > In both the reflection and the annotation proposals, the steps are: > > 1. Create styleable properties. > 2. That's it. > > It's just that step 1 also adds an annotation to the creation of > the property (which was/is a 2-step process anyway, declaring the > property and its?css metadata). > > Annotations also require a processor to read the data from their > values and target (the field/method). This is a bit of work, but > Michael's?CssMetaDataCache class is basically that - read the data > from the class (via reflection or annotations) and store it in a > map. The logic should be the same, just the method to obtain the > data is different. Both, as a result, have the benefits of > handling control/skin combinations (what I mentioned in the point > "Usable both in controls and in skins (or other classes)"). > > The benefit of co-locating the property and its css metadata in > the class itself also remains. > > To summarize, both approaches eliminate all the clutter of writing > styleable properties (John, will you like to create styleable > properties now? [1] :) ), both apply the flexibility of caching > per class, both allow better structuring of the class, but they > read the properties differently and have a different level of > declarativness. > > [1] > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044010.html > > On Tue, Dec 5, 2023 at 11:21?PM Andy Goryachev > wrote: > > I like the idea. > > I wonder if it is possible to reduce the amount of boilerplate > code?? For example, a CssMetaData can have a > > setGetter(Function> getter) > > method which supplies the property reference?? This way > CssMetaData.isSettable(Node) and > CssMetaData.getStyleableProperty(Node) can be implemented in > the base class (there are more complicated cases, so perhaps > setIsSettable(Predicate) would also be required). > > Example: > > CssMetaData.of("-fx-font", > Font.getDefault(), (n) -> n.font) > > Just a thought.? What do you think? > > -andy > > *From: *openjfx-dev on behalf > of Michael Strau? > *Date: *Sunday, December 3, 2023 at 22:02 > *To: *openjfx-dev > *Subject: *Reflective discovery of styleable properties > > Following up the discussion around the CssMetaData API, I'd > like to > chime in with yet another idea. To recap, here's Nir's summary > of the > current API [0]: > > "Let's look at what implementation is required from a user who > wants > to write their own styleable control: > 1. Create styleable properties. > 2. Create a list of these properties to be passed on. > 3. Create a public static method that returns the concatenation of > this list with the one of its parent. (This method happens to be > poorly documented, as mstr said.) > 4. Create a public non-static method that calls the static > method in a > forced-override pattern because otherwise you will be calling the > wrong static method. (This method's docs seem to be just wrong > because > you don't always want to delegate to Node's list.)" > > > I think this could reasonably be replaced with the following > implementation requirements: > 1. Create styleable properties. > 2. That's it. > > Let's look at what we're actually trying to do: create a list of > CSS-styleable property metadata of a class. But we can easily > do that > without all of the boilerplate code. > > When ?Node.getCssMetaData()` is invoked, all public methods of the > class are reflectively enumerated, and metadata is retrieved from > `Property` and `StyleableProperty` getters. This is a price that's > only paid once for any particular class (i.e. not for every > instance). > The resulting metadata list is cached and reused for all > instances of > that particular class. > > As a further optimization, metadata lists are also cached and > deduplicated for Control/Skin combinations (currently every > Control > instance has its own copy of the metadata list). > > Another benefit of this approach is that the CssMetaData can > now be > co-located with the property implementation, and not be kept > around in > other parts of the source code file. Here's how that looks > like when a > new "myValue" property is added to MyClass: > > StyleableDoubleProperty myValue = > ??????????? new SimpleStyleableDoubleProperty(this, "myValue") { > > ??????? static final CssMetaData METADATA = > ??????????? new CssMetaData( > "-fx-my-value", > SizeConverter.getInstance(), > USE_COMPUTED_SIZE) { > ??????????? @Override > ??????????? public boolean isSettable(MyClass node) { > ??????????????? return !node.myValue.isBound(); > ??????????? } > > ??????????? @Override > ??????????? public StyleableProperty getStyleableProperty( > MyClass node) { > ??????????????? return node.myValue; > ??????????? } > ??????? }; > > ??????? @Override > ??????? public CssMetaData getCssMetaData() { > ??????????? return METADATA; > ??????? } > ??? }; > > ??? public final DoubleProperty myValueProperty() { > ??????? return myValue; > ??? } > > It is not required to override the `getCssMetaData()` method, > nor is > it required to redeclare a new static `getClassCssMetaData()` > method. > It is also not required to manually keep the list of styleable > properties in sync with the list of CSS metadata. > > I've prototyped this concept for the `Node`, `Region` and > `Control` classes [1]. > > [0] > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044046.html > [1] https://github.com/openjdk/jfx/pull/1299 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpereda at openjdk.org Thu Dec 7 16:15:22 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 7 Dec 2023 16:15:22 GMT Subject: RFR: 8301302: Platform preferences API [v46] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <0Hf4MaXjapN0Fkyo_6AM8kFAhZZZM5mUgOYgoNw1gXs=.554e292f-d077-45cf-a999-b56c704afdc2@github.com> On Thu, 7 Dec 2023 01:05:44 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > renamed Windows.SPI.HighContrastOn to Windows.SPI.HighContrast Windows high contrast seems to work fine now. However, I'm building your PR (./gradlew sdk) and running the test on Mac, but I get: Exception in Application start method java.lang.reflect.InvocationTargetException ... Caused by: java.util.MissingResourceException: Can't find bundle for base name com/sun/glass/ui/win/themes, locale at java.base/java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:2045) at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1683) at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1575) at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1549) at java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:932) at javafx.graphics at 22-internal/com.sun.javafx.application.WindowsHighContrastScheme.lambda$static$0(WindowsHighContrastScheme.java:50) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:992) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575) at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616) at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622) at java.base/java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627) at javafx.graphics at 22-internal/com.sun.javafx.application.WindowsHighContrastScheme.(WindowsHighContrastScheme.java:52) ... 14 more ``` Note that files (classes, resources) from `com/sun/glass/ui/win/` are not added to the graphics jar when building for Linux or macOS (see build.gradle line 5103) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1845628673 From nlisker at gmail.com Thu Dec 7 16:19:30 2023 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 7 Dec 2023 18:19:30 +0200 Subject: [External] : Re: Reflective discovery of styleable properties In-Reply-To: References: Message-ID: > > Surely, you don't suggest we should change the CSS ref? > A lot of that reference is derived from the source code. As an example, look at all the Available CSS Properties tables. They contain the name, values, defaults that are specified in the code, and the superclass they inherit from. It's not a must because these change rarely, but it does eliminate inconsistencies and another place to update once a styleable property is added. On Thu, Dec 7, 2023 at 5:48?PM Andy Goryachev wrote: > > I think that the CSS reference should be generated from the source > code, which is something the annotation processor can do. > > > > Surely, you don't suggest we should change the CSS ref? > > > > > https://openjfx.io/javadoc/21/javafx.graphics/javafx/scene/doc-files/cssref.html > > > > I subscribe to a school of thought that requires specifications written by > humans for humans. The CSS reference is, in my opinion, an authoritative > source, so I would be against developing any tooling that generates it from > the source code. > > > > -andy > > > > > > *From: *Nir Lisker > *Date: *Thursday, December 7, 2023 at 01:54 > *To: *Andy Goryachev > *Cc: *Michael Strau? , openjfx-dev < > openjfx-dev at openjdk.org> > *Subject: *Re: [External] : Re: Reflective discovery of styleable > properties > > - I would recommend against the scanner figuring out the property name: > the property > names are codified by the CSS reference which serves as a > normative document in this case > > > > I think that the CSS reference should be generated from the source code, > which is something the annotation processor can do. > > > > - isSettable() logic might be more complex than (prop == null && > !(prop.isBound)), see Node.translateXProperty. How would that work with > annotations? > > > > From what John said, you can fall back to the CSSMetaData way if the > defaults are not good for you. > > > > On Wed, Dec 6, 2023 at 6:21?PM Andy Goryachev > wrote: > > I also like this idea very much. Still needs a reflective scanner, but > it's far more easier to understand and use. > > > > A couple of comments/questions: > > > > - I would recommend against the scanner figuring out the property name: > the property names are codified by the CSS reference which serves as a > normative document in this case > > > > - isSettable() logic might be more complex than (prop == null && > !(prop.isBound)), see Node.translateXProperty. How would that work with > annotations? > > > > What do you think? > > > > -andy > > > > > > > > *From: *Nir Lisker > *Date: *Wednesday, December 6, 2023 at 02:37 > *To: *Andy Goryachev > *Cc: *Michael Strau? , openjfx-dev < > openjfx-dev at openjdk.org> > *Subject: *[External] : Re: Reflective discovery of styleable properties > > I thought about the option of reflection, but I opted to propose > annotations instead. The following is my reasoning. > > > > Firstly, reflection is very magic-y. The author of the class has no > indication of what side effects happen due to the code they write, the > output (css handling in this case) comes out of nowhere from their > perspective. As with other reflection cases, it is a "pull" rather than > "push" approach - you don't write what should happen, you let someone else > decide that. For writers of skin/control classes, this means that they need > to know exactly what constitutes a hook for the reflection mechanism, or > face surprises. There is no compile time check that tells you whether you > have declared your styleable property properly or not (without an external > ad-hoc checker). > > We do this somewhat with properties - any method of the form > "...property()" gets special treatment, but this is for the docs. I don't > think we have code that depends on this other than in tests. > > > > Secondly, the proposed mechanism depends on the runtime type, not the > declared type. As a user, I see no indication in the API whether a property > is styleable or not. This is also (what I would consider) a problem with > the current state. When I thought about using reflection to solve this, I > at least thought to specify the declared type of the property as styleable, > like StyleableBooleanProperty instead of BooleanProperty (restricting the > returned type is backwards compatible). A downside of this is that it gives > access to the methods of StyleableProperty, which are not useful for the > user, I think, but maybe someone has a use for them. > > > > Thirdly, maybe I want to declare a styleable property not to be used > automatically. I can't think off the top of my head when I would want to do > that, but I'm also not a heavy css user. Are we sure that just initializing > a property with a styleable runtime type should *always* be caught by this > process? > > > > To compare, annotations have the following benefits: > > > > Firstly, they are declarative, which means no surprises for the class > author (WYSIWYG). This also allows more flexibility/control over which > properties get special treatment via an opt-in mechanism. > > > > Secondly, They can also be displayed in the JavaDocs (via @Documented) > with their assigned values. For example, the padding property of Region can > be annotated with @Styleable(property="-fx-padding"), informing the user > both that this value can be set by css, and how to do it. Interestingly, > the annotation doesn't need to be public API to be displayed, so we are not > bound by contracts. > > > > In terms of similarities: > > > > In both the reflection and the annotation proposals, the steps are: > > 1. Create styleable properties. > 2. That's it. > > It's just that step 1 also adds an annotation to the creation of the > property (which was/is a 2-step process anyway, declaring the property and > its css metadata). > > > > Annotations also require a processor to read the data from their values > and target (the field/method). This is a bit of work, but > Michael's CssMetaDataCache class is basically that - read the data from the > class (via reflection or annotations) and store it in a map. The logic > should be the same, just the method to obtain the data is different. Both, > as a result, have the benefits of handling control/skin combinations (what > I mentioned in the point "Usable both in controls and in skins (or other > classes)"). > > > > The benefit of co-locating the property and its css metadata in the class > itself also remains. > > > > > > To summarize, both approaches eliminate all the clutter of writing > styleable properties (John, will you like to create styleable properties > now? [1] :) ), both apply the flexibility of caching per class, both allow > better structuring of the class, but they read the properties differently > and have a different level of declarativness. > > > > [1] > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044010.html > > > > > > On Tue, Dec 5, 2023 at 11:21?PM Andy Goryachev > wrote: > > I like the idea. > > > > I wonder if it is possible to reduce the amount of boilerplate code? For > example, a CssMetaData can have a > > > > setGetter(Function> getter) > > > > method which supplies the property reference? This way > CssMetaData.isSettable(Node) and CssMetaData.getStyleableProperty(Node) can > be implemented in the base class (there are more complicated cases, so > perhaps setIsSettable(Predicate) would also be required). > > > > Example: > > > > CssMetaData.of("-fx-font", Font.getDefault(), (n) -> > n.font) > > > > Just a thought. What do you think? > > > > -andy > > > > > > *From: *openjfx-dev on behalf of Michael > Strau? > *Date: *Sunday, December 3, 2023 at 22:02 > *To: *openjfx-dev > *Subject: *Reflective discovery of styleable properties > > Following up the discussion around the CssMetaData API, I'd like to > chime in with yet another idea. To recap, here's Nir's summary of the > current API [0]: > > "Let's look at what implementation is required from a user who wants > to write their own styleable control: > 1. Create styleable properties. > 2. Create a list of these properties to be passed on. > 3. Create a public static method that returns the concatenation of > this list with the one of its parent. (This method happens to be > poorly documented, as mstr said.) > 4. Create a public non-static method that calls the static method in a > forced-override pattern because otherwise you will be calling the > wrong static method. (This method's docs seem to be just wrong because > you don't always want to delegate to Node's list.)" > > > I think this could reasonably be replaced with the following > implementation requirements: > 1. Create styleable properties. > 2. That's it. > > Let's look at what we're actually trying to do: create a list of > CSS-styleable property metadata of a class. But we can easily do that > without all of the boilerplate code. > > When ?Node.getCssMetaData()` is invoked, all public methods of the > class are reflectively enumerated, and metadata is retrieved from > `Property` and `StyleableProperty` getters. This is a price that's > only paid once for any particular class (i.e. not for every instance). > The resulting metadata list is cached and reused for all instances of > that particular class. > > As a further optimization, metadata lists are also cached and > deduplicated for Control/Skin combinations (currently every Control > instance has its own copy of the metadata list). > > Another benefit of this approach is that the CssMetaData can now be > co-located with the property implementation, and not be kept around in > other parts of the source code file. Here's how that looks like when a > new "myValue" property is added to MyClass: > > StyleableDoubleProperty myValue = > new SimpleStyleableDoubleProperty(this, "myValue") { > > static final CssMetaData METADATA = > new CssMetaData( > "-fx-my-value", > SizeConverter.getInstance(), > USE_COMPUTED_SIZE) { > @Override > public boolean isSettable(MyClass node) { > return !node.myValue.isBound(); > } > > @Override > public StyleableProperty getStyleableProperty( > MyClass node) { > return node.myValue; > } > }; > > @Override > public CssMetaData getCssMetaData() { > return METADATA; > } > }; > > public final DoubleProperty myValueProperty() { > return myValue; > } > > It is not required to override the `getCssMetaData()` method, nor is > it required to redeclare a new static `getClassCssMetaData()` method. > It is also not required to manually keep the list of styleable > properties in sync with the list of CSS metadata. > > I've prototyped this concept for the `Node`, `Region` and `Control` > classes [1]. > > [0] > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044046.html > [1] https://github.com/openjdk/jfx/pull/1299 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Dec 7 16:25:48 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Dec 2023 16:25:48 GMT Subject: RFR: 8301302: Platform preferences API [v46] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 7 Dec 2023 01:05:44 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > renamed Windows.SPI.HighContrastOn to Windows.SPI.HighContrast Good catch. I hadn't tested the latest update on Mac or Linux this time. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1845645389 From kcr at openjdk.org Thu Dec 7 16:34:25 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Dec 2023 16:34:25 GMT Subject: RFR: 8301302: Platform preferences API [v46] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 7 Dec 2023 01:05:44 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > renamed Windows.SPI.HighContrastOn to Windows.SPI.HighContrast Revoking my approval since the current patch is DOA on Mac and Linux. Once fixed, I'll fire off a headful test build prior to approving it. ------------- Changes requested by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1014#pullrequestreview-1770582203 From mstrauss at openjdk.org Thu Dec 7 17:21:05 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 7 Dec 2023 17:21:05 GMT Subject: RFR: 8301302: Platform preferences API [v47] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with three additional commits since the last revision: - removed unused import - javadoc - query resource bundles for high-contrast schemes only on Windows ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/efdab27b..3354782b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=46 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=45-46 Stats: 30 lines in 3 files changed: 9 ins; 10 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Thu Dec 7 17:21:08 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 7 Dec 2023 17:21:08 GMT Subject: RFR: 8301302: Platform preferences API [v46] In-Reply-To: <0Hf4MaXjapN0Fkyo_6AM8kFAhZZZM5mUgOYgoNw1gXs=.554e292f-d077-45cf-a999-b56c704afdc2@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <0Hf4MaXjapN0Fkyo_6AM8kFAhZZZM5mUgOYgoNw1gXs=.554e292f-d077-45cf-a999-b56c704afdc2@github.com> Message-ID: On Thu, 7 Dec 2023 16:12:21 GMT, Jose Pereda wrote: > Windows high contrast seems to work fine now. > > However, I'm building your PR (./gradlew sdk) and running the test on Mac, but I get: > > ``` > Exception in Application start method > java.lang.reflect.InvocationTargetException > ... > Caused by: java.util.MissingResourceException: Can't find bundle for base name com/sun/glass/ui/win/themes, locale > at java.base/java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:2045) > at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1683) > at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1575) > at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1549) > at java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:932) > at javafx.graphics at 22-internal/com.sun.javafx.application.WindowsHighContrastScheme.lambda$static$0(WindowsHighContrastScheme.java:50) > at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) > at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:992) > at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) > at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) > at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575) > at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) > at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616) > at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622) > at java.base/java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627) > at javafx.graphics at 22-internal/com.sun.javafx.application.WindowsHighContrastScheme.(WindowsHighContrastScheme.java:52) > ... 14 more > ``` > > Note that files (classes, resources) from `com/sun/glass/ui/win/` are not added to the graphics jar when building for Linux or macOS (see build.gradle line 5103) I've changed this so that these resources are only queried on Windows. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1845753809 From mstrauss at openjdk.org Thu Dec 7 17:21:12 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 7 Dec 2023 17:21:12 GMT Subject: RFR: 8301302: Platform preferences API [v46] In-Reply-To: <3LVyF0kJ4c6Z8OaJwiaMup82lAgyRvHmHNscYx0Pwok=.1268df6d-faf1-4358-bf18-3bc3882c96b0@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <3LVyF0kJ4c6Z8OaJwiaMup82lAgyRvHmHNscYx0Pwok=.1268df6d-faf1-4358-bf18-3bc3882c96b0@github.com> Message-ID: On Thu, 7 Dec 2023 15:24:11 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> renamed Windows.SPI.HighContrastOn to Windows.SPI.HighContrast > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java line 779: > >> 777: if (highContrastScheme == null) { >> 778: return; >> 779: } > > Minor: You could eliminate the null check if you defined a new "NONE" or "UNKNOWN" enum and restored the (no-op) `default:` on line 837. It's fine the way you have it, if you prefer. I've added a `NONE` constant. > modules/javafx.graphics/src/main/java/com/sun/javafx/application/WindowsHighContrastScheme.java line 80: > >> 78: // since we might be running on a JVM with a locale that is different from the OS. >> 79: for (WindowsHighContrastScheme item : values()) { >> 80: for (ResourceBundle resourceBundle : resourceBundles) { > > Depending on how often this is called, might it be worth caching a `Map` whose keys are the OS theme names and values are the corresponding enum values? This could be a follow-up enhancement if it were deemed important enough, but maybe it doesn't matter. This class will probably change a bit and be moved around if and when we add style themes, so I think we can revisit it then. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419313343 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419316074 From mstrauss at openjdk.org Thu Dec 7 17:21:13 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 7 Dec 2023 17:21:13 GMT Subject: RFR: 8301302: Platform preferences API [v46] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <3-YNC9hkgsuQDSDlEz02yLnVxVLVJSoHmMlWri-pimA=.3b00584b-ca36-4957-8a1b-c96b122f1fb5@github.com> On Thu, 7 Dec 2023 05:49:07 GMT, Nir Lisker wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> renamed Windows.SPI.HighContrastOn to Windows.SPI.HighContrast > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/WindowsHighContrastScheme.java line 74: > >> 72: if (themeName == null) { >> 73: return null; >> 74: } > > This method is called only from `PlatformImpl` that already does the `null` check on the the string. In general, `null` checks should be done on the "outer most layer" and then all the inner layers can rely on the value being non-null. > > Is this method expected to be called from other places as well? If not, the method can be made package visible. The method now returns `NONE` when another constant doesn't apply. I've removed the `public` modifier as you've suggested. > modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 79: > >> 77: >> 78: private final List invalidationListeners = new CopyOnWriteArrayList<>(); >> 79: private final List> mapChangeListeners = new CopyOnWriteArrayList<>(); > > Can these be modified concurrently? What is the need for `CopyOnWriteArrayList`? It's to prevent `ConcurrentModificationException` if a listener implementation adds or removes itself (or another listener). > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 37: > >> 35: import javafx.scene.input.KeyCode; >> 36: import javafx.scene.paint.Color; >> 37: import javafx.scene.paint.Paint; > > Unused import. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419304904 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419307136 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419308447 From mstrauss at openjdk.org Thu Dec 7 17:21:17 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 7 Dec 2023 17:21:17 GMT Subject: RFR: 8301302: Platform preferences API [v46] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 7 Dec 2023 15:43:48 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/javafx/application/ColorScheme.java line 35: >> >>> 33: * @since 22 >>> 34: */ >>> 35: public enum ColorScheme { >> >> Can there be future additions to this enum, or is its purpose to be limited to the current choices? > > I suspect this is limited to the current choices, but it's a good question. I think this will always be limited to these two choices. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419311825 From mstrauss at openjdk.org Thu Dec 7 17:33:23 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 7 Dec 2023 17:33:23 GMT Subject: RFR: 8301302: Platform preferences API [v46] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 7 Dec 2023 08:45:43 GMT, Nir Lisker wrote: > There are classes such as `PlatformPreferences`, `PreferenceProperties`, and `ColorSchemeProperty` that are effectively singletons. Does it makes sense to just write them in a singleton pattern to avoid misuse? If we add user-modifiable preferences, these won't be singletons. > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 587: > >> 585: >> 586: /** >> 587: * The color used for background regions. > > Maybe "The color used for background **of** regions"? But not all regions are backgrounds in this sense. > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 611: > >> 609: >> 610: /** >> 611: * The accent color. > > I think that this needs to explanation on what the accent color is. I'll create a follow-up issue for that. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1845786750 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419332384 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419336136 From mstrauss at openjdk.org Thu Dec 7 17:38:22 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 7 Dec 2023 17:38:22 GMT Subject: RFR: 8301302: Platform preferences API [v46] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 7 Dec 2023 08:04:45 GMT, Nir Lisker wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> renamed Windows.SPI.HighContrastOn to Windows.SPI.HighContrast > > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 589: > >> 587: * The color used for background regions. >> 588: *

>> 589: * If the platform does not report a background color, this property defaults to {@code Color.WHITE}. > > Is there value in writing this sentence on every property if they specify the `@defaultValue`? It might make it a bit more clear that this is the default value even on platforms that don't even have this preference. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419344928 From jpereda at openjdk.org Thu Dec 7 18:26:55 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 7 Dec 2023 18:26:55 GMT Subject: RFR: 8301302: Platform preferences API [v47] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 7 Dec 2023 17:21:05 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with three additional commits since the last revision: > > - removed unused import > - javadoc > - query resource bundles for high-contrast schemes only on Windows Manual test on macOS and Windows looks good now. I've left one comment modules/javafx.graphics/src/main/java/com/sun/javafx/application/WindowsHighContrastScheme.java line 43: > 41: * The high contrast feature may not be available on all platforms. > 42: */ > 43: enum WindowsHighContrastScheme { I'd rather keep the old name: `HighContrastScheme`: It is in a non-platform specific package, and it applies to all platforms (even only with `NONE`). You could add a comment about `HIGH_CONTRAST_*` enum constants being only available on Windows. ------------- PR Review: https://git.openjdk.org/jfx/pull/1014#pullrequestreview-1770790578 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419429539 From mstrauss at openjdk.org Thu Dec 7 18:33:26 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 7 Dec 2023 18:33:26 GMT Subject: RFR: 8301302: Platform preferences API [v47] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <2cb2M47P77HXs5qlFBkTXaDKyAbnEg-NQj_cMuGqfyM=.452450aa-edb4-4bc2-a298-b73966d55799@github.com> On Thu, 7 Dec 2023 18:17:58 GMT, Jose Pereda wrote: >> Michael Strau? has updated the pull request incrementally with three additional commits since the last revision: >> >> - removed unused import >> - javadoc >> - query resource bundles for high-contrast schemes only on Windows > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/WindowsHighContrastScheme.java line 43: > >> 41: * The high contrast feature may not be available on all platforms. >> 42: */ >> 43: enum WindowsHighContrastScheme { > > I'd rather keep the old name: `HighContrastScheme`: It is in a non-platform specific package, and it applies to all platforms (even only with `NONE`). > You could add a comment about `HIGH_CONTRAST_*` enum constants being only available on Windows. But it never applied to all platforms, it reflects exactly the Windows implementation of high-contrast schemes. It will be moved once we add style themes. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419444090 From kcr at openjdk.org Thu Dec 7 19:09:34 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Dec 2023 19:09:34 GMT Subject: RFR: 8301302: Platform preferences API [v47] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 7 Dec 2023 17:21:05 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with three additional commits since the last revision: > > - removed unused import > - javadoc > - query resource bundles for high-contrast schemes only on Windows I retested on all platforms. All green. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1014#pullrequestreview-1770842882 From jpereda at openjdk.org Thu Dec 7 19:09:42 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 7 Dec 2023 19:09:42 GMT Subject: RFR: 8301302: Platform preferences API [v47] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 7 Dec 2023 17:21:05 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with three additional commits since the last revision: > > - removed unused import > - javadoc > - query resource bundles for high-contrast schemes only on Windows Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1014#pullrequestreview-1770853699 From jpereda at openjdk.org Thu Dec 7 19:10:04 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 7 Dec 2023 19:10:04 GMT Subject: RFR: 8301302: Platform preferences API [v47] In-Reply-To: <2cb2M47P77HXs5qlFBkTXaDKyAbnEg-NQj_cMuGqfyM=.452450aa-edb4-4bc2-a298-b73966d55799@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <2cb2M47P77HXs5qlFBkTXaDKyAbnEg-NQj_cMuGqfyM=.452450aa-edb4-4bc2-a298-b73966d55799@github.com> Message-ID: On Thu, 7 Dec 2023 18:30:24 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/application/WindowsHighContrastScheme.java line 43: >> >>> 41: * The high contrast feature may not be available on all platforms. >>> 42: */ >>> 43: enum WindowsHighContrastScheme { >> >> I'd rather keep the old name: `HighContrastScheme`: It is in a non-platform specific package, and it applies to all platforms (even only with `NONE`). >> You could add a comment about `HIGH_CONTRAST_*` enum constants being only available on Windows. > > But it never applied to all platforms, it reflects exactly the Windows implementation of high-contrast schemes. It will be moved once we add style themes. ok ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419477427 From angorya at openjdk.org Thu Dec 7 19:12:17 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 7 Dec 2023 19:12:17 GMT Subject: RFR: 8301302: Platform preferences API [v47] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 7 Dec 2023 17:21:05 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with three additional commits since the last revision: > > - removed unused import > - javadoc > - query resource bundles for high-contrast schemes only on Windows Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1014#pullrequestreview-1770868868 From andy.goryachev at oracle.com Thu Dec 7 20:40:27 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 7 Dec 2023 20:40:27 +0000 Subject: ToggleButton behavior In-Reply-To: <487069A6-3B53-4EF7-A21E-D1A86474A1ED@martinfox.com> References: <487069A6-3B53-4EF7-A21E-D1A86474A1ED@martinfox.com> Message-ID: Dear Martin: It's hard to say. How does it work in Swing? There is also https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role I always felt that the focus management in JavaFX is underdeveloped: multiple focused nodes, nodes getting simultaneous input, lack of coherent geometry-based focus traversal policy, and a lack of public APIs for a custom focus traversal policy. Are there any ideas? -andy From: openjfx-dev on behalf of Martin Fox Date: Saturday, December 2, 2023 at 17:58 To: John Hendrikx Cc: openjfx-dev Subject: Re: ToggleButton behavior I took a look at the W3C accessibility guidelines for radio button groups since that?s the closest thing I could find to a group of ToggleButtons. The W3C suggests that Tab/Shift+Tab takes you in and out of the group and the arrow keys navigate within the group with wrap-around. Based on that (3) is correct. That?s where the W3C guidance ends; a single radio button doesn?t make much sense so it?s not even mentioned. I would expect a single ungrouped ToggleButton to navigate like a checkbox so (1) seems wrong. A group with just one ToggleButton is an odd thing so (2) could go either way. Martin On Dec 1, 2023, at 11:21?PM, John Hendrikx wrote: In my exploration of a potential Behavior API, I discovered this oddity in how ToggleButtons work. 1. If you have a single ToggleButton that is not part of a ToggleGroup, you can't navigate away from it with the arrow keys, only by using Tab or Shift-Tab. 2. If you have that same single ToggleButton, but it does have a group (a group of one) then you CAN navigate away from it with the arrow keys. 3. When you have two ToggleButtons, both part of the same group, then you can only navigate away from the group with Tab or Shift-Tab again, as the arrow keys will loop back to the first/last button when the end of the group is reached. I get the impression at least one of these is incorrect. I mean, either ToggleButtons should always loop, even if it is a group of one, meaning (2) would be incorrect... Or... ToggleButtons should never loop, in which case (1) and (3) are incorrect... Or... Single ToggleButtons (grouped or not) behave differently and don't do looping, in which case (1) is incorrect Thoughts? --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Thu Dec 7 21:36:19 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 7 Dec 2023 21:36:19 GMT Subject: RFR: 8301302: Platform preferences API [v44] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Dec 2023 21:48:46 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed bug in test application > > The value does indeed change: > macOS.NSColor.alternatingContentBackgroundColors = [0x1e1e1eff,0xffffff0c] > macOS.NSColor.alternatingContentBackgroundColors = [0xffffffff,0xf4f5f5ff] > > > private String f(Object x) { > if (x == null) { > return ""; > } > if (x.getClass().isArray()) { > int sz = Array.getLength(x); > StringBuilder sb = new StringBuilder(); > sb.append("["); > for (int i = 0; i < sz; i++) { > if (i > 0) { > sb.append(','); > } > sb.append(Array.get(x, i)); > } > sb.append("]"); > return sb.toString(); > } > return x.toString(); > } Thanks to all the people who were involved in developing this feature and helping to bring this across the finish line, especially @andy-goryachev-oracle @kevinrushforth @hjohn @nlisker and @jperedadnr ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1846141232 From mstrauss at openjdk.org Thu Dec 7 21:36:22 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 7 Dec 2023 21:36:22 GMT Subject: Integrated: 8301302: Platform preferences API In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <6ndKfZeZP6Ghm-dQ0TIgJ0FUZHvz_nYWUtLt_u13CUc=.4ec59439-f9ad-421d-8152-9e5931fafe5e@github.com> On Sun, 29 Jan 2023 01:33:48 GMT, Michael Strau? wrote: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. This pull request has now been integrated. Changeset: 170a4c15 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/170a4c1545696b095960c0e5dcbed1374d3f6ba6 Stats: 3432 lines in 35 files changed: 3287 ins; 108 del; 37 mod 8301302: Platform preferences API Reviewed-by: kcr, angorya, jpereda ------------- PR: https://git.openjdk.org/jfx/pull/1014 From michaelstrau2 at gmail.com Thu Dec 7 22:50:31 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Thu, 7 Dec 2023 23:50:31 +0100 Subject: Reflective discovery of styleable properties In-Reply-To: References: Message-ID: We could also use reflection in combination with annotations. You'd need to annotate every CSS-styleable property (a simple @Styleable annotation would suffice), and at runtime we can discover the annotated methods and reflect their metadata. This solves the problem that automatic styleable property discovery might be surprising for developers. From andy.goryachev at oracle.com Thu Dec 7 23:00:47 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 7 Dec 2023 23:00:47 +0000 Subject: Reflective discovery of styleable properties In-Reply-To: References: Message-ID: Could it be done with annotations alone? CssMetaData requires the following: - property name - object type - converter - initial value - inherits - list of sub-properties (of type List>) see Region But, if it is indeed possible, it would be a very good solution. -andy From: openjfx-dev on behalf of Michael Strau? Date: Thursday, December 7, 2023 at 14:51 To: Cc: openjfx-dev Subject: Re: Reflective discovery of styleable properties We could also use reflection in combination with annotations. You'd need to annotate every CSS-styleable property (a simple @Styleable annotation would suffice), and at runtime we can discover the annotated methods and reflect their metadata. This solves the problem that automatic styleable property discovery might be surprising for developers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Fri Dec 8 00:59:40 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 8 Dec 2023 00:59:40 GMT Subject: RFR: 8321434: Update Gradle to 8.5 Message-ID: Gradle 8.5.0 released on Nov 29, 2023, supports JDK 21. We need to update Gradle to 8.5 in order to update the boot JDK. There are not API level changes in Gradle that we need to work on, hence the change is only Gradle version update. Also, merging the PR with boot jdk update to 21.0.1 b12 ------------- Commit messages: - gradle update 8.5, boot jdk 19.0.1 b12 Changes: https://git.openjdk.org/jfx/pull/1300/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1300&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321434 Stats: 14 lines in 4 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1300.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1300/head:pull/1300 PR: https://git.openjdk.org/jfx/pull/1300 From nlisker at openjdk.org Fri Dec 8 04:56:59 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 8 Dec 2023 04:56:59 GMT Subject: RFR: 8301302: Platform preferences API [v47] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 7 Dec 2023 17:21:05 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with three additional commits since the last revision: > > - removed unused import > - javadoc > - query resource bundles for high-contrast schemes only on Windows On to phase 2 :) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1846545627 From mstrauss at openjdk.org Fri Dec 8 05:24:00 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 8 Dec 2023 05:24:00 GMT Subject: RFR: 8301302: Platform preferences API [v46] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 7 Dec 2023 17:28:25 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 611: >> >>> 609: >>> 610: /** >>> 611: * The accent color. >> >> I think that this needs to explanation on what the accent color is. > > I'll create a follow-up issue for that. Here it is: [JDK-8321573](https://bugs.openjdk.org/browse/JDK-8321573) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1419936734 From nlisker at gmail.com Fri Dec 8 08:29:34 2023 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 8 Dec 2023 10:29:34 +0200 Subject: [External] : Re: Reflective discovery of styleable properties In-Reply-To: <95597fae-5115-452b-ad37-c9b8dc649304@oracle.com> References: <95597fae-5115-452b-ad37-c9b8dc649304@oracle.com> Message-ID: It certainly can't all be generated, but what I said is that a lot of it can, like the class entries which include the class specifier and table. These are the majority of the document. The amount of work will depend on how far we will take the annotation or reflection route. Some of the suggestions we have go far enough that adding this won't be expensive. On Thu, Dec 7, 2023, 21:04 Kevin Rushforth wrote: > I haven't looked at this proposal yet, but there are some interesting > ideas here worth further discussion. > > I just wanted to weigh in on the cssref piece. As Andy indicated, > cssref.html is the normative specification for JavaFX CSS properties. And > no, it can't be (fully) auto-generated. > > The only way I could imagine tooling being involved is to auto-generate > the individual property tables for including in the html somehow (which > would need some sort of javadoc-inspired facility to add comments in the > table, etc). And while an interesting concept, it would likely be a rather > large effort for relatively little gain. > > -- Kevin > > > On 12/7/2023 7:48 AM, Andy Goryachev wrote: > > > I think that the CSS reference should be generated from the source > code, which is something the annotation processor can do. > > > > Surely, you don't suggest we should change the CSS ref? > > > > > https://openjfx.io/javadoc/21/javafx.graphics/javafx/scene/doc-files/cssref.html > > > > I subscribe to a school of thought that requires specifications written by > humans for humans. The CSS reference is, in my opinion, an authoritative > source, so I would be against developing any tooling that generates it from > the source code. > > > > -andy > > > > > > *From: *Nir Lisker > *Date: *Thursday, December 7, 2023 at 01:54 > *To: *Andy Goryachev > > *Cc: *Michael Strau? , > openjfx-dev > *Subject: *Re: [External] : Re: Reflective discovery of styleable > properties > > - I would recommend against the scanner figuring out the property name: > the property > names are codified by the CSS reference which serves as a > normative document in this case > > > > I think that the CSS reference should be generated from the source code, > which is something the annotation processor can do. > > > > - isSettable() logic might be more complex than (prop == null && > !(prop.isBound)), see Node.translateXProperty. How would that work with > annotations? > > > > From what John said, you can fall back to the CSSMetaData way if the > defaults are not good for you. > > > > On Wed, Dec 6, 2023 at 6:21?PM Andy Goryachev > wrote: > > I also like this idea very much. Still needs a reflective scanner, but > it's far more easier to understand and use. > > > > A couple of comments/questions: > > > > - I would recommend against the scanner figuring out the property name: > the property names are codified by the CSS reference which serves as a > normative document in this case > > > > - isSettable() logic might be more complex than (prop == null && > !(prop.isBound)), see Node.translateXProperty. How would that work with > annotations? > > > > What do you think? > > > > -andy > > > > > > > > *From: *Nir Lisker > *Date: *Wednesday, December 6, 2023 at 02:37 > *To: *Andy Goryachev > *Cc: *Michael Strau? , openjfx-dev < > openjfx-dev at openjdk.org> > *Subject: *[External] : Re: Reflective discovery of styleable properties > > I thought about the option of reflection, but I opted to propose > annotations instead. The following is my reasoning. > > > > Firstly, reflection is very magic-y. The author of the class has no > indication of what side effects happen due to the code they write, the > output (css handling in this case) comes out of nowhere from their > perspective. As with other reflection cases, it is a "pull" rather than > "push" approach - you don't write what should happen, you let someone else > decide that. For writers of skin/control classes, this means that they need > to know exactly what constitutes a hook for the reflection mechanism, or > face surprises. There is no compile time check that tells you whether you > have declared your styleable property properly or not (without an external > ad-hoc checker). > > We do this somewhat with properties - any method of the form > "...property()" gets special treatment, but this is for the docs. I don't > think we have code that depends on this other than in tests. > > > > Secondly, the proposed mechanism depends on the runtime type, not the > declared type. As a user, I see no indication in the API whether a property > is styleable or not. This is also (what I would consider) a problem with > the current state. When I thought about using reflection to solve this, I > at least thought to specify the declared type of the property as styleable, > like StyleableBooleanProperty instead of BooleanProperty (restricting the > returned type is backwards compatible). A downside of this is that it gives > access to the methods of StyleableProperty, which are not useful for the > user, I think, but maybe someone has a use for them. > > > > Thirdly, maybe I want to declare a styleable property not to be used > automatically. I can't think off the top of my head when I would want to do > that, but I'm also not a heavy css user. Are we sure that just initializing > a property with a styleable runtime type should *always* be caught by this > process? > > > > To compare, annotations have the following benefits: > > > > Firstly, they are declarative, which means no surprises for the class > author (WYSIWYG). This also allows more flexibility/control over which > properties get special treatment via an opt-in mechanism. > > > > Secondly, They can also be displayed in the JavaDocs (via @Documented) > with their assigned values. For example, the padding property of Region can > be annotated with @Styleable(property="-fx-padding"), informing the user > both that this value can be set by css, and how to do it. Interestingly, > the annotation doesn't need to be public API to be displayed, so we are not > bound by contracts. > > > > In terms of similarities: > > > > In both the reflection and the annotation proposals, the steps are: > > 1. Create styleable properties. > 2. That's it. > > It's just that step 1 also adds an annotation to the creation of the > property (which was/is a 2-step process anyway, declaring the property and > its css metadata). > > > > Annotations also require a processor to read the data from their values > and target (the field/method). This is a bit of work, but > Michael's CssMetaDataCache class is basically that - read the data from the > class (via reflection or annotations) and store it in a map. The logic > should be the same, just the method to obtain the data is different. Both, > as a result, have the benefits of handling control/skin combinations (what > I mentioned in the point "Usable both in controls and in skins (or other > classes)"). > > > > The benefit of co-locating the property and its css metadata in the class > itself also remains. > > > > > > To summarize, both approaches eliminate all the clutter of writing > styleable properties (John, will you like to create styleable properties > now? [1] :) ), both apply the flexibility of caching per class, both allow > better structuring of the class, but they read the properties differently > and have a different level of declarativness. > > > > [1] > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044010.html > > > > > > On Tue, Dec 5, 2023 at 11:21?PM Andy Goryachev > wrote: > > I like the idea. > > > > I wonder if it is possible to reduce the amount of boilerplate code? For > example, a CssMetaData can have a > > > > setGetter(Function> getter) > > > > method which supplies the property reference? This way > CssMetaData.isSettable(Node) and CssMetaData.getStyleableProperty(Node) can > be implemented in the base class (there are more complicated cases, so > perhaps setIsSettable(Predicate) would also be required). > > > > Example: > > > > CssMetaData.of("-fx-font", Font.getDefault(), (n) -> > n.font) > > > > Just a thought. What do you think? > > > > -andy > > > > > > *From: *openjfx-dev on behalf of Michael > Strau? > *Date: *Sunday, December 3, 2023 at 22:02 > *To: *openjfx-dev > *Subject: *Reflective discovery of styleable properties > > Following up the discussion around the CssMetaData API, I'd like to > chime in with yet another idea. To recap, here's Nir's summary of the > current API [0]: > > "Let's look at what implementation is required from a user who wants > to write their own styleable control: > 1. Create styleable properties. > 2. Create a list of these properties to be passed on. > 3. Create a public static method that returns the concatenation of > this list with the one of its parent. (This method happens to be > poorly documented, as mstr said.) > 4. Create a public non-static method that calls the static method in a > forced-override pattern because otherwise you will be calling the > wrong static method. (This method's docs seem to be just wrong because > you don't always want to delegate to Node's list.)" > > > I think this could reasonably be replaced with the following > implementation requirements: > 1. Create styleable properties. > 2. That's it. > > Let's look at what we're actually trying to do: create a list of > CSS-styleable property metadata of a class. But we can easily do that > without all of the boilerplate code. > > When ?Node.getCssMetaData()` is invoked, all public methods of the > class are reflectively enumerated, and metadata is retrieved from > `Property` and `StyleableProperty` getters. This is a price that's > only paid once for any particular class (i.e. not for every instance). > The resulting metadata list is cached and reused for all instances of > that particular class. > > As a further optimization, metadata lists are also cached and > deduplicated for Control/Skin combinations (currently every Control > instance has its own copy of the metadata list). > > Another benefit of this approach is that the CssMetaData can now be > co-located with the property implementation, and not be kept around in > other parts of the source code file. Here's how that looks like when a > new "myValue" property is added to MyClass: > > StyleableDoubleProperty myValue = > new SimpleStyleableDoubleProperty(this, "myValue") { > > static final CssMetaData METADATA = > new CssMetaData( > "-fx-my-value", > SizeConverter.getInstance(), > USE_COMPUTED_SIZE) { > @Override > public boolean isSettable(MyClass node) { > return !node.myValue.isBound(); > } > > @Override > public StyleableProperty getStyleableProperty( > MyClass node) { > return node.myValue; > } > }; > > @Override > public CssMetaData getCssMetaData() { > return METADATA; > } > }; > > public final DoubleProperty myValueProperty() { > return myValue; > } > > It is not required to override the `getCssMetaData()` method, nor is > it required to redeclare a new static `getClassCssMetaData()` method. > It is also not required to manually keep the list of styleable > properties in sync with the list of CSS metadata. > > I've prototyped this concept for the `Node`, `Region` and `Control` > classes [1]. > > [0] > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044046.html > [1] https://github.com/openjdk/jfx/pull/1299 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri Dec 8 13:16:23 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Dec 2023 13:16:23 GMT Subject: RFR: 8321434: Update Gradle to 8.5 In-Reply-To: References: Message-ID: <4p-C_21T9Y-quGE9XSMl0LTeRN48_xWLb1_jEbos0ug=.e62767c7-b5cd-4bb8-b21d-bab63a8c6ebb@github.com> On Fri, 8 Dec 2023 00:53:56 GMT, Ambarish Rapte wrote: > Gradle 8.5.0 released on Nov 29, 2023, supports JDK 21. > We need to update Gradle to 8.5 in order to update the boot JDK. > There are not API level changes in Gradle that we need to work on, hence the change is only Gradle version update. > > Also, merging the PR with boot jdk update to 21.0.1 b12 Note to reviewers: this does _not_ change the minimum version of the JDK needed to build or run JavaFX, which remains at JDK 17. Nor does it change the minimum version of gradle. However, if you do use JDK 21.x to build (which will be used by GHA and our production builds after this is integrated), then you will need gradle 8.5. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1300#issuecomment-1847147695 From kcr at openjdk.org Fri Dec 8 13:16:24 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Dec 2023 13:16:24 GMT Subject: RFR: 8321434: Update Gradle to 8.5 In-Reply-To: <4p-C_21T9Y-quGE9XSMl0LTeRN48_xWLb1_jEbos0ug=.e62767c7-b5cd-4bb8-b21d-bab63a8c6ebb@github.com> References: <4p-C_21T9Y-quGE9XSMl0LTeRN48_xWLb1_jEbos0ug=.e62767c7-b5cd-4bb8-b21d-bab63a8c6ebb@github.com> Message-ID: <1xQ0c1BEAjSdM-gur1SAyM2D51rHhBpkzWgD8LlmB2Q=.b1af34a1-d128-4d5e-8996-e2bb6f048581@github.com> On Fri, 8 Dec 2023 13:13:31 GMT, Kevin Rushforth wrote: >> Gradle 8.5.0 released on Nov 29, 2023, supports JDK 21. >> We need to update Gradle to 8.5 in order to update the boot JDK. >> There are not API level changes in Gradle that we need to work on, hence the change is only Gradle version update. >> >> Also, merging the PR with boot jdk update to 21.0.1 b12 > > Note to reviewers: this does _not_ change the minimum version of the JDK needed to build or run JavaFX, which remains at JDK 17. Nor does it change the minimum version of gradle. However, if you do use JDK 21.x to build (which will be used by GHA and our production builds after this is integrated), then you will need gradle 8.5. Reviewers: @kevinrushforth and either @johanvos or @tiainen ------------- PR Comment: https://git.openjdk.org/jfx/pull/1300#issuecomment-1847148241 From kcr at openjdk.org Fri Dec 8 14:15:27 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Dec 2023 14:15:27 GMT Subject: RFR: 8321434: Update Gradle to 8.5 In-Reply-To: References: Message-ID: On Fri, 8 Dec 2023 00:53:56 GMT, Ambarish Rapte wrote: > Gradle 8.5.0 released on Nov 29, 2023, supports JDK 21. > We need to update Gradle to 8.5 in order to update the boot JDK. > There are not API level changes in Gradle that we need to work on, hence the change is only Gradle version update. > > Also, merging the PR with boot jdk update to 21.0.1 b12 Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1300#pullrequestreview-1772433070 From nlisker at openjdk.org Fri Dec 8 14:40:26 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 8 Dec 2023 14:40:26 GMT Subject: RFR: 8321434: Update Gradle to 8.5 In-Reply-To: References: Message-ID: On Fri, 8 Dec 2023 00:53:56 GMT, Ambarish Rapte wrote: > Gradle 8.5.0 released on Nov 29, 2023, supports JDK 21. > We need to update Gradle to 8.5 in order to update the boot JDK. > There are not API level changes in Gradle that we need to work on, hence the change is only Gradle version update. > > Also, merging the PR with boot jdk update to 21.0.1 b12 I just ran a build with this setup. The build succeeded (I didn't build Webkit). Is there anything else to test? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1300#issuecomment-1847292869 From jvos at openjdk.org Fri Dec 8 14:49:28 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Dec 2023 14:49:28 GMT Subject: RFR: 8321434: Update Gradle to 8.5 In-Reply-To: References: Message-ID: On Fri, 8 Dec 2023 14:37:31 GMT, Nir Lisker wrote: > I just ran a build with this setup. The build succeeded (I didn't build Webkit). Is there anything else to test? We typically do a full build, with SDK's and JMOD's and Javadoc etc, on the supported platforms. Given the large amount of platform-specific code in our gradle files, this is something that needs to be tested on different platforms. (We're running tests currently as well). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1300#issuecomment-1847308894 From kcr at openjdk.org Fri Dec 8 15:43:24 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Dec 2023 15:43:24 GMT Subject: RFR: 8321434: Update Gradle to 8.5 In-Reply-To: References: Message-ID: On Fri, 8 Dec 2023 14:47:04 GMT, Johan Vos wrote: > We typically do a full build, with SDK's and JMOD's and Javadoc etc, on the supported platforms. Given the large amount of platform-specific code in our gradle files, this is something that needs to be tested on different platforms. Yes, exactly. The GHA run or a simple developer build is a good first-order test, but by no means sufficient. Ambarish ran a full CI build, including building WebKit and running all headful tests prior to submitting the PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1300#issuecomment-1847403334 From sykora at openjdk.org Fri Dec 8 16:23:22 2023 From: sykora at openjdk.org (Joeri Sykora) Date: Fri, 8 Dec 2023 16:23:22 GMT Subject: RFR: 8321434: Update Gradle to 8.5 In-Reply-To: References: Message-ID: On Fri, 8 Dec 2023 00:53:56 GMT, Ambarish Rapte wrote: > Gradle 8.5.0 released on Nov 29, 2023, supports JDK 21. > We need to update Gradle to 8.5 in order to update the boot JDK. > There are not API level changes in Gradle that we need to work on, hence the change is only Gradle version update. > > Also, merging the PR with boot jdk update to 21.0.1 b12 I ran the full build with tests on the major platforms and everything worked fine. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1300#pullrequestreview-1772757644 From mstrauss at openjdk.org Sat Dec 9 07:12:40 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 9 Dec 2023 07:12:40 GMT Subject: RFR: 8321573: Enhance documentation for Platform.Preferences.accentColor Message-ID: This PR enhances the documentation of `Platform.Preferences.accentColor`: /** - * The accent color. + * The accent color, which is usually a vivid color that contrasts with the foreground + * and background colors. It can be used to highlight the active or important part of a + * control and make it stand out from the rest of the user interface. ------------- Commit messages: - added accent color documentation Changes: https://git.openjdk.org/jfx/pull/1301/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1301&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321573 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1301.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1301/head:pull/1301 PR: https://git.openjdk.org/jfx/pull/1301 From nlisker at openjdk.org Sat Dec 9 07:28:23 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 9 Dec 2023 07:28:23 GMT Subject: RFR: 8321573: Enhance documentation for Platform.Preferences.accentColor In-Reply-To: References: Message-ID: On Sat, 9 Dec 2023 07:07:27 GMT, Michael Strau? wrote: > This PR enhances the documentation of `Platform.Preferences.accentColor`: > > > /** > - * The accent color. > + * The accent color, which is usually a vivid color that contrasts with the foreground > + * and background colors. It can be used to highlight the active or important part of a > + * control and make it stand out from the rest of the user interface. I noticed unrelated points: 1. The properties use the phrasing "If the platform does not report..." except for the one for color scheme, which uses "The value of this property defaults to". Might want to use the same phrasing for color scheme too. 2. The default value for the foreground color is specified as `Color.BLACK` instead of `Color#BLACK`. modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 612: > 610: * The accent color, which is usually a vivid color that contrasts with the foreground > 611: * and background colors. It can be used to highlight the active or important part of a > 612: * control and make it stand out from the rest of the user interface. I think it's more important to say what it's used for than what value is should have, so I would switch the order: The accent color, which can be used to highlight the active or important part of a control and make it stand out from the rest of the user interface. It is usually a vivid color that contrasts with the foreground and background colors. ------------- PR Review: https://git.openjdk.org/jfx/pull/1301#pullrequestreview-1773566634 PR Review Comment: https://git.openjdk.org/jfx/pull/1301#discussion_r1421301210 From mstrauss at openjdk.org Sat Dec 9 08:40:31 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 9 Dec 2023 08:40:31 GMT Subject: RFR: 8321573: Improve Platform.Preferences documentation [v2] In-Reply-To: References: Message-ID: > This PR enhances the documentation of `Platform.Preferences.accentColor`: > > > /** > - * The accent color. > + * The accent color, which can be used to highlight the active or important part of a > + * control and make it stand out from the rest of the user interface. It is usually a > + * vivid color that contrasts with the foreground and background colors. > > > Additional changes include alternating row colors for tables. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: wording, table styling ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1301/files - new: https://git.openjdk.org/jfx/pull/1301/files/89858a90..c1e78a04 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1301&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1301&range=00-01 Stats: 22 lines in 1 file changed: 9 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/1301.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1301/head:pull/1301 PR: https://git.openjdk.org/jfx/pull/1301 From mstrauss at openjdk.org Sat Dec 9 08:40:34 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 9 Dec 2023 08:40:34 GMT Subject: RFR: 8321573: Improve Platform.Preferences documentation [v2] In-Reply-To: References: Message-ID: <0dZxf7o8tpeT4g-x_D7yfb7lcyMhZy8bBBkdKwD5D-0=.ad999b21-8bb6-4cc0-bcdb-be5a5c29e2ed@github.com> On Sat, 9 Dec 2023 07:25:17 GMT, Nir Lisker wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> wording, table styling > > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 612: > >> 610: * The accent color, which is usually a vivid color that contrasts with the foreground >> 611: * and background colors. It can be used to highlight the active or important part of a >> 612: * control and make it stand out from the rest of the user interface. > > I think it's more important to say what it's used for than what value is should have, so I would switch the order: > > The accent color, which can be used to highlight the active or important part of a > control and make it stand out from the rest of the user interface. It is usually a vivid > color that contrasts with the foreground and background colors. Yes, that's better. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1301#discussion_r1421359899 From nlisker at openjdk.org Sat Dec 9 09:36:24 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 9 Dec 2023 09:36:24 GMT Subject: RFR: 8321573: Improve Platform.Preferences documentation [v2] In-Reply-To: References: Message-ID: On Sat, 9 Dec 2023 08:40:31 GMT, Michael Strau? wrote: >> This PR enhances the documentation of `Platform.Preferences.accentColor`: >> >> >> /** >> - * The accent color. >> + * The accent color, which can be used to highlight the active or important part of a >> + * control and make it stand out from the rest of the user interface. It is usually a >> + * vivid color that contrasts with the foreground and background colors. >> >> >> Additional changes include alternating row colors for tables. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > wording, table styling Looks good. Let's keep it open until Monday to give others a chance to review. modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 596: > 594: * The color used for background regions. > 595: *

> 596: * If the platform does not report a background color, this property defaults to {@link Color#WHITE}. Minor: I don't think you need a link here because it's linked in the default value tag. ------------- Marked as reviewed by nlisker (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1301#pullrequestreview-1773646552 PR Review Comment: https://git.openjdk.org/jfx/pull/1301#discussion_r1421378662 From kpk at openjdk.org Sat Dec 9 13:35:25 2023 From: kpk at openjdk.org (Karthik P K) Date: Sat, 9 Dec 2023 13:35:25 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v7] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: On Thu, 2 Nov 2023 15:31:40 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 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 26 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - tolerance > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - undo merge > - no new api > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - cleanup > - using snap inner space api > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge branch 'ag.8311527.snap.inner' into 8299753.resize > - ... and 16 more: https://git.openjdk.org/jfx/compare/b4cdf7d6...5e855022 Tested the changes in Windows 11 with different scale values. The fix works as expected. I will review the code soon and complete the review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1848411826 From eran at leshem.life Sat Dec 9 14:44:01 2023 From: eran at leshem.life (Eran Leshem) Date: Sat, 9 Dec 2023 16:44:01 +0200 Subject: Converting a Color object to its string representation Message-ID: <066201da2aae$2729d520$757d7f60$@leshem.life> Hello, Can I contribute an implementation for https://bugs.openjdk.org/browse/JDK-8090778? Eran -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Sat Dec 9 16:28:22 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 9 Dec 2023 16:28:22 GMT Subject: RFR: 8321573: Improve Platform.Preferences documentation [v2] In-Reply-To: References: Message-ID: <-7nGbG3HfqDFVGup9h4m5kTYogHH4D5WIu49p2Aaeuw=.26cd5b93-77aa-47b4-8231-4e0b8fd3f384@github.com> On Sat, 9 Dec 2023 16:20:30 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> wording, table styling > > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 473: > >> 471: *

>> 472: * The following preferences are potentially available on the specified platforms: >> 473: *

> > I recommend changing the ID to `id="preferences-table-windows"` and adding `id="preferences-table-macos"` and `id="preferences-table-linux"` to the other two. And if you do that, you will need to change the link on line 448 of this file. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1301#discussion_r1421442350 From kcr at openjdk.org Sat Dec 9 16:28:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 9 Dec 2023 16:28:21 GMT Subject: RFR: 8321573: Improve Platform.Preferences documentation [v2] In-Reply-To: References: Message-ID: On Sat, 9 Dec 2023 08:40:31 GMT, Michael Strau? wrote: >> This PR enhances the documentation of `Platform.Preferences.accentColor`: >> >> >> /** >> - * The accent color. >> + * The accent color, which can be used to highlight the active or important part of a >> + * control and make it stand out from the rest of the user interface. It is usually a >> + * vivid color that contrasts with the foreground and background colors. >> >> >> Additional changes include alternating row colors for tables. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > wording, table styling Updated docs look good. I left a comment about the html `id` of the tables. modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 473: > 471: *

> 472: * The following preferences are potentially available on the specified platforms: > 473: *

I recommend changing the ID to `id="preferences-table-windows"` and adding `id="preferences-table-macos"` and `id="preferences-table-linux"` to the other two. ------------- PR Review: https://git.openjdk.org/jfx/pull/1301#pullrequestreview-1773720598 PR Review Comment: https://git.openjdk.org/jfx/pull/1301#discussion_r1421441742 From kcr at openjdk.org Sat Dec 9 16:28:25 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 9 Dec 2023 16:28:25 GMT Subject: RFR: 8321573: Improve Platform.Preferences documentation [v2] In-Reply-To: References: Message-ID: On Sat, 9 Dec 2023 09:33:13 GMT, Nir Lisker wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> wording, table styling > > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 596: > >> 594: * The color used for background regions. >> 595: *

>> 596: * If the platform does not report a background color, this property defaults to {@link Color#WHITE}. > > Minor: I don't think you need a link here because it's linked in the default value tag. Agreed. Only one one of them needs the link (and yes, it's minor). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1301#discussion_r1421441931 From mstrauss at openjdk.org Sat Dec 9 17:55:32 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 9 Dec 2023 17:55:32 GMT Subject: RFR: 8321573: Improve Platform.Preferences documentation [v3] In-Reply-To: References: Message-ID: > This PR enhances the documentation of `Platform.Preferences.accentColor`: > > > /** > - * The accent color. > + * The accent color, which can be used to highlight the active or important part of a > + * control and make it stand out from the rest of the user interface. It is usually a > + * vivid color that contrasts with the foreground and background colors. > > > Additional changes include alternating row colors for tables. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1301/files - new: https://git.openjdk.org/jfx/pull/1301/files/c1e78a04..24e3e1bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1301&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1301&range=01-02 Stats: 9 lines in 1 file changed: 2 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1301.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1301/head:pull/1301 PR: https://git.openjdk.org/jfx/pull/1301 From michaelstrau2 at gmail.com Sat Dec 9 18:19:49 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sat, 9 Dec 2023 19:19:49 +0100 Subject: Converting a Color object to its string representation In-Reply-To: <066201da2aae$2729d520$757d7f60$@leshem.life> References: <066201da2aae$2729d520$757d7f60$@leshem.life> Message-ID: If we are going to revisit the `Color` class, maybe we want to provide a more comprehensive string formatting API, for example: - full-length web strings (e.g. "#ffad341c") - compact web strings (e.g. "#ccc") - with/without the leading # - nearest named color ("darkgoldenrod") On Sat, Dec 9, 2023 at 3:44?PM Eran Leshem wrote: > > Hello, > > > > Can I contribute an implementation for https://bugs.openjdk.org/browse/JDK-8090778? > > > > Eran > > From davidalayachew at gmail.com Sat Dec 9 20:38:52 2023 From: davidalayachew at gmail.com (David Alayachew) Date: Sat, 9 Dec 2023 15:38:52 -0500 Subject: Converting a Color object to its string representation In-Reply-To: References: <066201da2aae$2729d520$757d7f60$@leshem.life> Message-ID: Doesn't HexDigits cover 3/4 of these cases? On Sat, Dec 9, 2023, 1:20 PM Michael Strau? wrote: > If we are going to revisit the `Color` class, maybe we want to provide > a more comprehensive string formatting API, for example: > - full-length web strings (e.g. "#ffad341c") > - compact web strings (e.g. "#ccc") > - with/without the leading # > - nearest named color ("darkgoldenrod") > > > On Sat, Dec 9, 2023 at 3:44?PM Eran Leshem wrote: > > > > Hello, > > > > > > > > Can I contribute an implementation for > https://bugs.openjdk.org/browse/JDK-8090778? > > > > > > > > Eran > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Sat Dec 9 20:40:25 2023 From: davidalayachew at gmail.com (David Alayachew) Date: Sat, 9 Dec 2023 15:40:25 -0500 Subject: Converting a Color object to its string representation In-Reply-To: References: <066201da2aae$2729d520$757d7f60$@leshem.life> Message-ID: Apologies - java.util.HexFormat That's what I get for firing from the hip, then looking afterwards. On Sat, Dec 9, 2023, 3:38 PM David Alayachew wrote: > Doesn't HexDigits cover 3/4 of these cases? > > On Sat, Dec 9, 2023, 1:20 PM Michael Strau? > wrote: > >> If we are going to revisit the `Color` class, maybe we want to provide >> a more comprehensive string formatting API, for example: >> - full-length web strings (e.g. "#ffad341c") >> - compact web strings (e.g. "#ccc") >> - with/without the leading # >> - nearest named color ("darkgoldenrod") >> >> >> On Sat, Dec 9, 2023 at 3:44?PM Eran Leshem wrote: >> > >> > Hello, >> > >> > >> > >> > Can I contribute an implementation for >> https://bugs.openjdk.org/browse/JDK-8090778? >> > >> > >> > >> > Eran >> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Sat Dec 9 20:57:59 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sat, 9 Dec 2023 21:57:59 +0100 Subject: Converting a Color object to its string representation In-Reply-To: References: <066201da2aae$2729d520$757d7f60$@leshem.life> Message-ID: How would HexFormat work with Color, other than using an extremely unwieldy syntax? String formatted = HexFormat.of() .withDelimiter("#") .formatHex(new byte[] { (byte)(color.getRed() * 255.0f), (byte)(color.getGreen() * 255.0f), (byte)(color.getBlue() * 255.0f), (byte)(color.getOpacity() * 255.0f) }); On Sat, Dec 9, 2023 at 9:40?PM David Alayachew wrote: > > Apologies - java.util.HexFormat > > That's what I get for firing from the hip, then looking afterwards. From michaelstrau2 at gmail.com Sat Dec 9 21:06:32 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sat, 9 Dec 2023 22:06:32 +0100 Subject: Converting a Color object to its string representation In-Reply-To: References: <066201da2aae$2729d520$757d7f60$@leshem.life> Message-ID: I obviously meant to write withPrefix("#"), not withDelimiter("#")... On Sat, Dec 9, 2023 at 9:57?PM Michael Strau? wrote: > > How would HexFormat work with Color, other than using an extremely > unwieldy syntax? > > String formatted = HexFormat.of() > .withDelimiter("#") > .formatHex(new byte[] { > (byte)(color.getRed() * 255.0f), > (byte)(color.getGreen() * 255.0f), > (byte)(color.getBlue() * 255.0f), > (byte)(color.getOpacity() * 255.0f) > }); > > > > On Sat, Dec 9, 2023 at 9:40?PM David Alayachew wrote: > > > > Apologies - java.util.HexFormat > > > > That's what I get for firing from the hip, then looking afterwards. From john.hendrikx at gmail.com Sat Dec 9 21:34:41 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sat, 9 Dec 2023 22:34:41 +0100 Subject: Converting a Color object to its string representation In-Reply-To: References: <066201da2aae$2729d520$757d7f60$@leshem.life> Message-ID: <99dbc381-c979-4fcd-c030-7ee0c7f72131@gmail.com> I think this is too niche to have Color provide. Just make a utility method for whatever format you desire, instead of making Color responsible for half a dozen ways of formatting colors, and then probably still missing some format that someone needs. Ticket should be closed as won't fix. --John On 09/12/2023 22:06, Michael Strau? wrote: > I obviously meant to write withPrefix("#"), not withDelimiter("#")... > > On Sat, Dec 9, 2023 at 9:57?PM Michael Strau? wrote: >> How would HexFormat work with Color, other than using an extremely >> unwieldy syntax? >> >> String formatted = HexFormat.of() >> .withDelimiter("#") >> .formatHex(new byte[] { >> (byte)(color.getRed() * 255.0f), >> (byte)(color.getGreen() * 255.0f), >> (byte)(color.getBlue() * 255.0f), >> (byte)(color.getOpacity() * 255.0f) >> }); >> >> >> >> On Sat, Dec 9, 2023 at 9:40?PM David Alayachew wrote: >>> Apologies - java.util.HexFormat >>> >>> That's what I get for firing from the hip, then looking afterwards. From kcr at openjdk.org Mon Dec 11 13:05:28 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Dec 2023 13:05:28 GMT Subject: RFR: 8321573: Improve Platform.Preferences documentation [v3] In-Reply-To: References: Message-ID: On Sat, 9 Dec 2023 17:55:32 GMT, Michael Strau? wrote: >> This PR enhances the documentation of `Platform.Preferences.accentColor`: >> >> >> /** >> - * The accent color. >> + * The accent color, which can be used to highlight the active or important part of a >> + * control and make it stand out from the rest of the user interface. It is usually a >> + * vivid color that contrasts with the foreground and background colors. >> >> >> Additional changes include alternating row colors for tables. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1301#pullrequestreview-1775094674 From kcr at openjdk.org Mon Dec 11 13:17:12 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Dec 2023 13:17:12 GMT Subject: RFR: 8321626: [testbug] Mark DualWindowTest and ContextMenuNPETest unstable on Linux Message-ID: Until JDK-8321624 and JDK-8321625 are fixed, mark the following two tests as unstable on Linux, meaning they will not be run as part of our nightly headful test runs. DualWindowTest - [JDK-8321624](https://bugs.openjdk.org/browse/JDK-8321624) ContextMenuNPETest - [JDK-8321625](https://bugs.openjdk.org/browse/JDK-8321625) These two tests are causing a lot of noise in our CI headful test runs. By skipping these two tests, we get clean test runs. ------------- Commit messages: - 8321626: [testbug] Mark DualWindowTest and ContextMenuNPETest unstable on Linux Changes: https://git.openjdk.org/jfx/pull/1302/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1302&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321626 Stats: 14 lines in 2 files changed: 14 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1302.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1302/head:pull/1302 PR: https://git.openjdk.org/jfx/pull/1302 From kcr at openjdk.org Mon Dec 11 13:17:34 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Dec 2023 13:17:34 GMT Subject: RFR: 8321636: [testbug] Skip failing 3D lighting tests on macOS 14 / aarch64 Message-ID: Until [JDK-8318985](https://bugs.openjdk.org/browse/JDK-8318985) is fixed, we will skip the 4 failing 3D light tests on Mac / aarch64 if the macOS version is 14, meaning they will not be run as part of our nightly headful test runs or developer test build. ------------- Commit messages: - 8321636: [testbug] Skip failing 3D lighting tests on macOS 14 / aarch64 Changes: https://git.openjdk.org/jfx/pull/1303/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1303&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321636 Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1303.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1303/head:pull/1303 PR: https://git.openjdk.org/jfx/pull/1303 From nlisker at openjdk.org Mon Dec 11 13:36:29 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 11 Dec 2023 13:36:29 GMT Subject: RFR: 8321573: Improve Platform.Preferences documentation [v3] In-Reply-To: References: Message-ID: <0u2IVZiXxf5NMNwdnHkwISWCW6PZ78VFAA1mqpPzDhg=.8e16dc47-f364-4884-ac6e-c772da5682c1@github.com> On Sat, 9 Dec 2023 17:55:32 GMT, Michael Strau? wrote: >> This PR enhances the documentation of `Platform.Preferences.accentColor`: >> >> >> /** >> - * The accent color. >> + * The accent color, which can be used to highlight the active or important part of a >> + * control and make it stand out from the rest of the user interface. It is usually a >> + * vivid color that contrasts with the foreground and background colors. >> >> >> Additional changes include alternating row colors for tables. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by nlisker (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1301#pullrequestreview-1775151711 From angorya at openjdk.org Mon Dec 11 15:41:26 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 11 Dec 2023 15:41:26 GMT Subject: RFR: 8321636: [testbug] Skip failing 3D lighting tests on macOS 14 / aarch64 In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 13:13:04 GMT, Kevin Rushforth wrote: > Until [JDK-8318985](https://bugs.openjdk.org/browse/JDK-8318985) is fixed, we will skip the 4 failing 3D light tests on Mac / aarch64 if the macOS version is 14, meaning they will not be run as part of our nightly headful test runs or developer test build. Marked as reviewed by angorya (Reviewer). tests/system/src/test/java/test/robot/test3d/PointLightIlluminationTest.java line 70: > 68: private static volatile Scene testScene = null; > 69: > 70: // Used to skip failing tests until JDK-8318985 is fixed we probably should add a note in JDK-8318985 description so we won't forget to revert these changes. ------------- PR Review: https://git.openjdk.org/jfx/pull/1303#pullrequestreview-1775458711 PR Review Comment: https://git.openjdk.org/jfx/pull/1303#discussion_r1422669207 From kcr at openjdk.org Mon Dec 11 16:32:28 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Dec 2023 16:32:28 GMT Subject: RFR: 8321636: [testbug] Skip failing 3D lighting tests on macOS 14 / aarch64 In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 15:39:03 GMT, Andy Goryachev wrote: >> Until [JDK-8318985](https://bugs.openjdk.org/browse/JDK-8318985) is fixed, we will skip the 4 failing 3D light tests on Mac / aarch64 if the macOS version is 14, meaning they will not be run as part of our nightly headful test runs or developer test build. > > tests/system/src/test/java/test/robot/test3d/PointLightIlluminationTest.java line 70: > >> 68: private static volatile Scene testScene = null; >> 69: >> 70: // Used to skip failing tests until JDK-8318985 is fixed > > we probably should add a note in JDK-8318985 description so we won't forget to revert these changes. Good idea. I added a comment to that JBS bug. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1303#discussion_r1422766539 From mstrauss at openjdk.org Mon Dec 11 17:14:33 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 11 Dec 2023 17:14:33 GMT Subject: Integrated: 8321573: Improve Platform.Preferences documentation In-Reply-To: References: Message-ID: On Sat, 9 Dec 2023 07:07:27 GMT, Michael Strau? wrote: > This PR enhances the documentation of `Platform.Preferences.accentColor`: > > > /** > - * The accent color. > + * The accent color, which can be used to highlight the active or important part of a > + * control and make it stand out from the rest of the user interface. It is usually a > + * vivid color that contrasts with the foreground and background colors. > > > Additional changes include alternating row colors for tables. This pull request has now been integrated. Changeset: 60476ef7 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/60476ef79e472546e5b19843185b15d4506034c7 Stats: 25 lines in 1 file changed: 13 ins; 1 del; 11 mod 8321573: Improve Platform.Preferences documentation Reviewed-by: nlisker, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1301 From jpereda at openjdk.org Mon Dec 11 18:42:59 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 11 Dec 2023 18:42:59 GMT Subject: RFR: 8321722: Tab header flickering when dragging slowly other tabs and reordering uncompleted Message-ID: This PR prevents changes in direction when dragging a tab header over a TabPane control, if delta value is zero, which can happen with slow drag events, in order to prevent starting and stopping too frequently the animation of the target tab header in opposite directions. ------------- Commit messages: - Prevent changes in direction when dragging if delta value is zero Changes: https://git.openjdk.org/jfx/pull/1304/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1304&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321722 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1304.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1304/head:pull/1304 PR: https://git.openjdk.org/jfx/pull/1304 From kcr at openjdk.org Mon Dec 11 18:54:31 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Dec 2023 18:54:31 GMT Subject: RFR: 8321722: Tab header flickering when dragging slowly other tabs and reordering uncompleted In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 18:36:35 GMT, Jose Pereda wrote: > This PR prevents changes in direction when dragging a tab header over a TabPane control, if delta value is zero, which can happen with slow drag events, in order to prevent starting and stopping too frequently the animation of the target tab header in opposite directions. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 2162: > 2160: } > 2161: // Stop dropHeaderAnim if direction of drag is changed > 2162: if (dragDirection != 0 && prevDragDirection != dragDirection) { Did you mean `dragDelta != 0`? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1304#discussion_r1422992199 From kcr at openjdk.org Mon Dec 11 18:58:31 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Dec 2023 18:58:31 GMT Subject: Integrated: 8321636: [testbug] Skip failing 3D lighting tests on macOS 14 / aarch64 In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 13:13:04 GMT, Kevin Rushforth wrote: > Until [JDK-8318985](https://bugs.openjdk.org/browse/JDK-8318985) is fixed, we will skip the 4 failing 3D light tests on Mac / aarch64 if the macOS version is 14, meaning they will not be run as part of our nightly headful test runs or developer test build. This pull request has now been integrated. Changeset: b389f6d2 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/b389f6d2ab1b0fd2eae6e954aa376b57c87741fb Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod 8321636: [testbug] Skip failing 3D lighting tests on macOS 14 / aarch64 Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1303 From angorya at openjdk.org Mon Dec 11 19:04:33 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 11 Dec 2023 19:04:33 GMT Subject: RFR: 8321722: Tab header flickering when dragging slowly other tabs and reordering uncompleted In-Reply-To: References: Message-ID: <4syRQU4AOjJHDt7Tr59Ye-IHR4Z1JDmjXlUQBjRV-1U=.721c401c-d1f6-425c-9c7b-bb8e0fa292b7@github.com> On Mon, 11 Dec 2023 18:36:35 GMT, Jose Pereda wrote: > This PR prevents changes in direction when dragging a tab header over a TabPane control, if delta value is zero, which can happen with slow drag events, in order to prevent starting and stopping too frequently the animation of the target tab header in opposite directions. the fix works on macOS 14.1.1 ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1304#pullrequestreview-1775972862 From angorya at openjdk.org Mon Dec 11 19:04:34 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 11 Dec 2023 19:04:34 GMT Subject: RFR: 8321722: Tab header flickering when dragging slowly other tabs and reordering uncompleted In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 18:51:09 GMT, Kevin Rushforth wrote: >> This PR prevents changes in direction when dragging a tab header over a TabPane control, if delta value is zero, which can happen with slow drag events, in order to prevent starting and stopping too frequently the animation of the target tab header in opposite directions. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 2162: > >> 2160: } >> 2161: // Stop dropHeaderAnim if direction of drag is changed >> 2162: if (dragDirection != 0 && prevDragDirection != dragDirection) { > > Did you mean `dragDelta != 0`? it is sort of equivalent in this case... I think this code is correct. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1304#discussion_r1423002773 From jpereda at openjdk.org Mon Dec 11 19:07:33 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 11 Dec 2023 19:07:33 GMT Subject: RFR: 8321722: Tab header flickering when dragging slowly other tabs and reordering uncompleted In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 19:01:19 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 2162: >> >>> 2160: } >>> 2161: // Stop dropHeaderAnim if direction of drag is changed >>> 2162: if (dragDirection != 0 && prevDragDirection != dragDirection) { >> >> Did you mean `dragDelta != 0`? > > it is sort of equivalent in this case... > I think this code is correct. It is the same as using `dragDelta != 0`, since `dragDelta = 0` implies `dragDirection = 0`. The if-else expression doesn't provide a value for the case `dragDelta == 0`, so I've added an initial value 0 to `dragDirection`. Since `prevDragDirection` initial value is -1, we need to verify that `dragDirection` is not zero and also `prevDragDirection` is different to `dragDirection` to detect a change of direction. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1304#discussion_r1423005976 From mstrauss at openjdk.org Mon Dec 11 19:42:34 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 11 Dec 2023 19:42:34 GMT Subject: RFR: 8321722: Tab header flickering when dragging slowly other tabs and reordering uncompleted In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 18:36:35 GMT, Jose Pereda wrote: > This PR prevents changes in direction when dragging a tab header over a TabPane control, if delta value is zero, which can happen with slow drag events, in order to prevent starting and stopping too frequently the animation of the target tab header in opposite directions. LGTM ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1304#pullrequestreview-1776030113 From kcr at openjdk.org Mon Dec 11 20:00:30 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Dec 2023 20:00:30 GMT Subject: RFR: 8321722: Tab header flickering when dragging slowly other tabs and reordering uncompleted In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 19:04:49 GMT, Jose Pereda wrote: >> it is sort of equivalent in this case... >> I think this code is correct. > > It is the same as using `dragDelta != 0`, since `dragDelta = 0` implies `dragDirection = 0`. > > The if-else expression doesn't provide a value for the case `dragDelta == 0`, so I've added an initial value 0 to `dragDirection`. > > Since `prevDragDirection` initial value is -1, we need to verify that `dragDirection` is not zero and also `prevDragDirection` is different to `dragDirection` to detect a change of direction. Right. Thanks for the clarification. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1304#discussion_r1423055173 From org.openjdk at io7m.com Mon Dec 11 20:58:19 2023 From: org.openjdk at io7m.com (Mark Raynsford) Date: Mon, 11 Dec 2023 20:58:19 +0000 Subject: Possible to deploy patched openjfx locally? Message-ID: <6e531802871e33a5290005ebac285884bb93b3e9.camel@io7m.com> Hello! I'm attempting to experiment with some patches to OpenJFX locally. Is there a straightforward way to publish the resulting jar files to my local ~/.m2 repository? There appears to be a `MAVEN_PUBLISH` property, but this just results in: $ sh gradlew -PMAVEN_PUBLISH=true sdk ... * What went wrong: A problem occurred configuring root project 'jfx'. > Failed to notify project evaluation listener. > Could not find method classifier() for arguments [linux] on task ':base:modularPublicationJarLinux' of type org.gradle.api.tasks.bundling.Jar. > Could not find method classifier() for arguments [linux] on task ':graphics:modularPublicationJarLinux' of type org.gradle.api.tasks.bundling.Jar. > Could not find method classifier() for arguments [linux] on task ':controls:modularPublicationJarLinux' of type org.gradle.api.tasks.bundling.Jar. > Could not find method classifier() for arguments [linux] on task ':swing:modularPublicationJarLinux' of type org.gradle.api.tasks.bundling.Jar. > Could not find method classifier() for arguments [linux] on task ':fxml:modularPublicationJarLinux' of type org.gradle.api.tasks.bundling.Jar. > Could not find method classifier() for arguments [linux] on task ':media:modularPublicationJarLinux' of type org.gradle.api.tasks.bundling.Jar. > Could not find method classifier() for arguments [linux] on task ':web:modularPublicationJarLinux' of type org.gradle.api.tasks.bundling.Jar. -- Mark Raynsford | https://www.io7m.com From kcr at openjdk.org Mon Dec 11 21:01:34 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Dec 2023 21:01:34 GMT Subject: RFR: 8321722: Tab header flickering when dragging slowly other tabs and reordering uncompleted In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 18:36:35 GMT, Jose Pereda wrote: > This PR prevents changes in direction when dragging a tab header over a TabPane control, if delta value is zero, which can happen with slow drag events, in order to prevent starting and stopping too frequently the animation of the target tab header in opposite directions. Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1304#pullrequestreview-1776158565 From eran at leshem.life Mon Dec 11 21:17:59 2023 From: eran at leshem.life (Eran Leshem) Date: Mon, 11 Dec 2023 23:17:59 +0200 Subject: Converting a Color object to its string representation In-Reply-To: <99dbc381-c979-4fcd-c030-7ee0c7f72131@gmail.com> References: <066201da2aae$2729d520$757d7f60$@leshem.life> <99dbc381-c979-4fcd-c030-7ee0c7f72131@gmail.com> Message-ID: <079901da2c77$85199e70$8f4cdb50$@leshem.life> Thank you for your responses. Given that the framework requires colors in string format in its style APIs, I think it should provide some way to convert colors to strings as expected by these APIs. Otherwise, clients are forced to implement this bridging logic on their own, due to a framework gap. And given that Color already parses these string representations, I think it makes sense for it to provide the inverse conversion. Eran -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-retn at openjdk.org] On Behalf Of John Hendrikx Sent: Saturday, December 09, 2023 11:35 PM To: openjfx-dev at openjdk.org Subject: Re: Converting a Color object to its string representation I think this is too niche to have Color provide. Just make a utility method for whatever format you desire, instead of making Color responsible for half a dozen ways of formatting colors, and then probably still missing some format that someone needs. Ticket should be closed as won't fix. --John On 09/12/2023 22:06, Michael Strau? wrote: > I obviously meant to write withPrefix("#"), not withDelimiter("#")... > > On Sat, Dec 9, 2023 at 9:57?PM Michael Strau? wrote: >> How would HexFormat work with Color, other than using an extremely >> unwieldy syntax? >> >> String formatted = HexFormat.of() >> .withDelimiter("#") >> .formatHex(new byte[] { >> (byte)(color.getRed() * 255.0f), >> (byte)(color.getGreen() * 255.0f), >> (byte)(color.getBlue() * 255.0f), >> (byte)(color.getOpacity() * 255.0f) >> }); >> >> >> >> On Sat, Dec 9, 2023 at 9:40?PM David Alayachew wrote: >>> Apologies - java.util.HexFormat >>> >>> That's what I get for firing from the hip, then looking afterwards. From jpereda at openjdk.org Mon Dec 11 23:06:34 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 11 Dec 2023 23:06:34 GMT Subject: Integrated: 8321722: Tab header flickering when dragging slowly other tabs and reordering uncompleted In-Reply-To: References: Message-ID: <1rDDs59S4RqJX0L3edJLRxNG4e3KVRqSRekenwqdfOo=.905c7289-fdf6-4459-a371-309eacfe98e5@github.com> On Mon, 11 Dec 2023 18:36:35 GMT, Jose Pereda wrote: > This PR prevents changes in direction when dragging a tab header over a TabPane control, if delta value is zero, which can happen with slow drag events, in order to prevent starting and stopping too frequently the animation of the target tab header in opposite directions. This pull request has now been integrated. Changeset: a20f4bcd Author: Jose Pereda URL: https://git.openjdk.org/jfx/commit/a20f4bcd54c5ae2a3e19324e51ce1f4cc172e32f Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8321722: Tab header flickering when dragging slowly other tabs and reordering uncompleted Reviewed-by: angorya, mstrauss, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1304 From swpalmer at gmail.com Tue Dec 12 01:11:39 2023 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 11 Dec 2023 20:11:39 -0500 Subject: Converting a Color object to its string representation In-Reply-To: <079901da2c77$85199e70$8f4cdb50$@leshem.life> References: <079901da2c77$85199e70$8f4cdb50$@leshem.life> Message-ID: <1BB9FE54-1C72-4B7A-9F45-E55C02DDAA54@gmail.com> I agree. I was going to write pretty much this exact email, but you beat me to it. I was implementing some user-configurable colour customizations in an application and needed to do it with style sheets, along with something that reads colours along the lines of what the new platform preferences API does. I make a base64 data URL from a dynamically generated style sheet to avoid writing temp CSS files to style the app. I also needed to do this to work around the style sheet having higher priority than programmatically set colours as per my misunderstanding in https://bugs.openjdk.org/browse/JDK-8317434 So I see value in having Color implement something like this. Scott > On Dec 11, 2023, at 4:19?PM, Eran Leshem wrote: > > ?Thank you for your responses. > > Given that the framework requires colors in string format in its style APIs, I think it should provide some way to convert colors to strings as expected by these APIs. Otherwise, clients are forced to implement this bridging logic on their own, due to a framework gap. > > And given that Color already parses these string representations, I think it makes sense for it to provide the inverse conversion. > > Eran > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-retn at openjdk.org] On Behalf Of John Hendrikx > Sent: Saturday, December 09, 2023 11:35 PM > To: openjfx-dev at openjdk.org > Subject: Re: Converting a Color object to its string representation > > I think this is too niche to have Color provide. > > Just make a utility method for whatever format you desire, instead of > making Color responsible for half a dozen ways of formatting colors, and > then probably still missing some format that someone needs. > > Ticket should be closed as won't fix. > > --John > >> On 09/12/2023 22:06, Michael Strau? wrote: >> I obviously meant to write withPrefix("#"), not withDelimiter("#")... >> >>> On Sat, Dec 9, 2023 at 9:57?PM Michael Strau? wrote: >>> How would HexFormat work with Color, other than using an extremely >>> unwieldy syntax? >>> >>> String formatted = HexFormat.of() >>> .withDelimiter("#") >>> .formatHex(new byte[] { >>> (byte)(color.getRed() * 255.0f), >>> (byte)(color.getGreen() * 255.0f), >>> (byte)(color.getBlue() * 255.0f), >>> (byte)(color.getOpacity() * 255.0f) >>> }); >>> >>> >>> >>> On Sat, Dec 9, 2023 at 9:40?PM David Alayachew wrote: >>>> Apologies - java.util.HexFormat >>>> >>>> That's what I get for firing from the hip, then looking afterwards. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Tue Dec 12 05:41:35 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 12 Dec 2023 05:41:35 GMT Subject: Integrated: 8321434: Update Gradle to 8.5 In-Reply-To: References: Message-ID: On Fri, 8 Dec 2023 00:53:56 GMT, Ambarish Rapte wrote: > Gradle 8.5.0 released on Nov 29, 2023, supports JDK 21. > We need to update Gradle to 8.5 in order to update the boot JDK. > There are not API level changes in Gradle that we need to work on, hence the change is only Gradle version update. > > Also, merging the PR with boot jdk update to 21.0.1 b12 This pull request has now been integrated. Changeset: f03bb74f Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/f03bb74f8847126340cbf23379ad9669ff0074a6 Stats: 14 lines in 4 files changed: 0 ins; 0 del; 14 mod 8321434: Update Gradle to 8.5 8321435: Update boot JDK to 21.0.1 Reviewed-by: kcr, sykora ------------- PR: https://git.openjdk.org/jfx/pull/1300 From kpk at openjdk.org Tue Dec 12 06:16:32 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 12 Dec 2023 06:16:32 GMT Subject: RFR: 8321626: [testbug] Mark DualWindowTest and ContextMenuNPETest unstable on Linux In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 13:10:55 GMT, Kevin Rushforth wrote: > Until JDK-8321624 and JDK-8321625 are fixed, mark the following two tests as unstable on Linux, meaning they will not be run as part of our nightly headful test runs. > > DualWindowTest - [JDK-8321624](https://bugs.openjdk.org/browse/JDK-8321624) > ContextMenuNPETest - [JDK-8321625](https://bugs.openjdk.org/browse/JDK-8321625) > > These two tests are causing a lot of noise in our CI headful test runs. By skipping these two tests, we get clean test runs. LGTM ------------- Marked as reviewed by kpk (Committer). PR Review: https://git.openjdk.org/jfx/pull/1302#pullrequestreview-1776721988 From arapte at openjdk.org Tue Dec 12 07:08:32 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 12 Dec 2023 07:08:32 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v2] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 08:00:58 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > process reviewers comments Looks all good to me. Is it possible to add an automated test ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1851414942 From john.hendrikx at gmail.com Tue Dec 12 10:29:47 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 12 Dec 2023 11:29:47 +0100 Subject: Possible to deploy patched openjfx locally? In-Reply-To: <6e531802871e33a5290005ebac285884bb93b3e9.camel@io7m.com> References: <6e531802871e33a5290005ebac285884bb93b3e9.camel@io7m.com> Message-ID: Hi, Depending on what you want to do, if you're not using modules, you can just place a changed source file with your own sources (in their original package) and it should override it. What also works (without modules) is to have a Maven module that has JFX as dependencies, and place changed source files there to override / patch things. It's a really fast method as you don't need to build JFX at all, and I often use it to try out minor bug fixes, or to test small new features. --John On 11/12/2023 21:58, Mark Raynsford wrote: > Hello! > > I'm attempting to experiment with some patches to OpenJFX locally. > > Is there a straightforward way to publish the resulting jar files to my > local ~/.m2 repository? > > There appears to be a `MAVEN_PUBLISH` property, but this just results > in: > > $ sh gradlew -PMAVEN_PUBLISH=true sdk > ... > * What went wrong: > A problem occurred configuring root project 'jfx'. >> Failed to notify project evaluation listener. > > Could not find method classifier() for arguments [linux] on task > ':base:modularPublicationJarLinux' of type > org.gradle.api.tasks.bundling.Jar. > > Could not find method classifier() for arguments [linux] on task > ':graphics:modularPublicationJarLinux' of type > org.gradle.api.tasks.bundling.Jar. > > Could not find method classifier() for arguments [linux] on task > ':controls:modularPublicationJarLinux' of type > org.gradle.api.tasks.bundling.Jar. > > Could not find method classifier() for arguments [linux] on task > ':swing:modularPublicationJarLinux' of type > org.gradle.api.tasks.bundling.Jar. > > Could not find method classifier() for arguments [linux] on task > ':fxml:modularPublicationJarLinux' of type > org.gradle.api.tasks.bundling.Jar. > > Could not find method classifier() for arguments [linux] on task > ':media:modularPublicationJarLinux' of type > org.gradle.api.tasks.bundling.Jar. > > Could not find method classifier() for arguments [linux] on task > ':web:modularPublicationJarLinux' of type > org.gradle.api.tasks.bundling.Jar. > From jpereda at openjdk.org Tue Dec 12 11:24:42 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 12 Dec 2023 11:24:42 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland Message-ID: This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. ------------- Commit messages: - Add wrappers of gdk_seat_grab and gdk_seat_ungrab Changes: https://git.openjdk.org/jfx/pull/1305/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1305&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320965 Stats: 96 lines in 5 files changed: 88 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1305.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1305/head:pull/1305 PR: https://git.openjdk.org/jfx/pull/1305 From org.openjdk at io7m.com Tue Dec 12 12:10:35 2023 From: org.openjdk at io7m.com (Mark Raynsford) Date: Tue, 12 Dec 2023 12:10:35 +0000 Subject: Possible to deploy patched openjfx locally? In-Reply-To: References: <6e531802871e33a5290005ebac285884bb93b3e9.camel@io7m.com> Message-ID: <6f600cd027e7593f9dbffd7fb363c2a3f5f95ab6.camel@io7m.com> On Tue, 2023-12-12 at 11:29 +0100, John Hendrikx wrote: > Hi, > > Depending on what you want to do, if you're not using modules, you > can > just place a changed source file with your own sources (in their > original package) and it should override it. > Hehe, thanks! I had forgotten that that was even an option. I would normally be using modules, but for the sake of testing purposes, I'll be doing this instead. -- Mark Raynsford | https://www.io7m.com From bruno.carle at gmail.com Tue Dec 12 12:23:28 2023 From: bruno.carle at gmail.com (Bruno Carle) Date: Tue, 12 Dec 2023 13:23:28 +0100 Subject: Possible to deploy patched openjfx locally? In-Reply-To: <6e531802871e33a5290005ebac285884bb93b3e9.camel@io7m.com> References: <6e531802871e33a5290005ebac285884bb93b3e9.camel@io7m.com> Message-ID: Hi Mark, that worked for me recently: in build.gradle change line 546: defineProperty("MAVEN_PUBLISH", "true") and line 1730: (add brackets) artifact (project.tasks."modularPublicationJar$t.capital") { then sh ./gradlew publishToMavenLocal Regards Bruno On Mon, Dec 11, 2023 at 9:59?PM Mark Raynsford wrote: > Hello! > > I'm attempting to experiment with some patches to OpenJFX locally. > > Is there a straightforward way to publish the resulting jar files to my > local ~/.m2 repository? > > There appears to be a `MAVEN_PUBLISH` property, but this just results > in: > > $ sh gradlew -PMAVEN_PUBLISH=true sdk > ... > * What went wrong: > A problem occurred configuring root project 'jfx'. > > Failed to notify project evaluation listener. > > Could not find method classifier() for arguments [linux] on task > ':base:modularPublicationJarLinux' of type > org.gradle.api.tasks.bundling.Jar. > > Could not find method classifier() for arguments [linux] on task > ':graphics:modularPublicationJarLinux' of type > org.gradle.api.tasks.bundling.Jar. > > Could not find method classifier() for arguments [linux] on task > ':controls:modularPublicationJarLinux' of type > org.gradle.api.tasks.bundling.Jar. > > Could not find method classifier() for arguments [linux] on task > ':swing:modularPublicationJarLinux' of type > org.gradle.api.tasks.bundling.Jar. > > Could not find method classifier() for arguments [linux] on task > ':fxml:modularPublicationJarLinux' of type > org.gradle.api.tasks.bundling.Jar. > > Could not find method classifier() for arguments [linux] on task > ':media:modularPublicationJarLinux' of type > org.gradle.api.tasks.bundling.Jar. > > Could not find method classifier() for arguments [linux] on task > ':web:modularPublicationJarLinux' of type > org.gradle.api.tasks.bundling.Jar. > > -- > Mark Raynsford | https://www.io7m.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Tue Dec 12 13:21:32 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 12 Dec 2023 13:21:32 GMT Subject: RFR: 8321626: [testbug] Mark DualWindowTest and ContextMenuNPETest unstable on Linux In-Reply-To: References: Message-ID: <3hsU856DDeKYgAO4zTiugcpju4wzbDuggyqAXBa_U18=.0c6a6ba0-2602-41d4-a487-51b1128031ed@github.com> On Mon, 11 Dec 2023 13:10:55 GMT, Kevin Rushforth wrote: > Until JDK-8321624 and JDK-8321625 are fixed, mark the following two tests as unstable on Linux, meaning they will not be run as part of our nightly headful test runs. > > DualWindowTest - [JDK-8321624](https://bugs.openjdk.org/browse/JDK-8321624) > ContextMenuNPETest - [JDK-8321625](https://bugs.openjdk.org/browse/JDK-8321625) > > These two tests are causing a lot of noise in our CI headful test runs. By skipping these two tests, we get clean test runs. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1302#pullrequestreview-1777450273 From kcr at openjdk.org Tue Dec 12 13:58:30 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 12 Dec 2023 13:58:30 GMT Subject: Integrated: 8321626: [testbug] Mark DualWindowTest and ContextMenuNPETest unstable on Linux In-Reply-To: References: Message-ID: <7Ji-lPinHtdLewAJGEYiiZLAfaufiyoWV56xhgqJfNI=.3fe02837-ebb3-4ed9-9ea4-e8c66cbf3672@github.com> On Mon, 11 Dec 2023 13:10:55 GMT, Kevin Rushforth wrote: > Until JDK-8321624 and JDK-8321625 are fixed, mark the following two tests as unstable on Linux, meaning they will not be run as part of our nightly headful test runs. > > DualWindowTest - [JDK-8321624](https://bugs.openjdk.org/browse/JDK-8321624) > ContextMenuNPETest - [JDK-8321625](https://bugs.openjdk.org/browse/JDK-8321625) > > These two tests are causing a lot of noise in our CI headful test runs. By skipping these two tests, we get clean test runs. This pull request has now been integrated. Changeset: e69f266b Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/e69f266b3acd4ca1d63d43442a9a3c9cc540613e Stats: 14 lines in 2 files changed: 14 ins; 0 del; 0 mod 8321626: [testbug] Mark DualWindowTest and ContextMenuNPETest unstable on Linux Reviewed-by: kpk, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1302 From org.openjdk at io7m.com Tue Dec 12 14:10:21 2023 From: org.openjdk at io7m.com (Mark Raynsford) Date: Tue, 12 Dec 2023 14:10:21 +0000 Subject: The crisp fonts saga Message-ID: Hello! I've never been particularly satisfied with the font rendering in JavaFX. In particular, on Linux, the text always appears very soft and blurry compared to non-JavaFX applications on the same system. Even applications that render antialiased text with Java2D seem to look better. I decided to take a look into it to see if anything could be done about this, and I have some questions. I'm only looking at the Freetype implementation in Prism currently, as that's all I can realistically test on at the moment. For reference, here's how text rendered at 16px using Terminus TTF looks today: https://ataxia.io7m.com/2023/12/12/hinting_nobitmaps_normal.png I'm not sure if I'm alone on this, but I find this almost migraine- inducing. No other application on my system, including those that use Freetype, using that font at that size will render as blurry as that. Looking at modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/FTFo ntFile.java, I see this in initGlyph(): ``` int flags = OSFreetype.FT_LOAD_RENDER | OSFreetype.FT_LOAD_NO_HINTING | OSFreetype.FT_LOAD_NO_BITMAP; ``` Additionally, the code might also add the FT_LOAD_TARGET_NORMAL or FT_LOAD_TARGET_LCD flags later, but I'll assume FT_LOAD_TARGET_NORMAL for the sake of avoiding combinatorial explosions in testing at this point. Essentially, we discard hinting information, and we discard bitmap information. I'm not sure why we do either of these things. I decided to try different combinations of flags to see what would happen. Here's FT_LOAD_RENDER | FT_LOAD_NO_BITMAP (no bitmaps, but using hinting data): https://ataxia.io7m.com/2023/12/12/hinting_nobitmaps_normal.png That's no real improvement. Here's FT_LOAD_RENDER | FT_LOAD_NO_HINTING (ignore hinting data, but use bitmaps if they are included): https://ataxia.io7m.com/2023/12/12/nohinting_bitmaps_normal.png That, to my poor suffering eyes, is already a _vast_ improvement. Let's try including both hinting and bitmaps (FT_LOAD_RENDER): https://ataxia.io7m.com/2023/12/12/hinting_bitmaps_normal.png Inspecting that in an image editor shows the pixels of the text to be identical. So, clearly, Terminus TTF includes bitmaps for smaller text sizes. Let's try another font such as Droid Sans that renders crisply at ~10pt sizes on my system, and that I'm reasonably confident doesn't include any bitmaps. Here's the JavaFX default (FT_LOAD_NO_HINTING | FT_LOAD_NO_BITMAP): https://ataxia.io7m.com/2023/12/12/droid_12_nohinting_nobitmaps.png That's pretty nasty. Let's enable hinting (FT_LOAD_NO_BITMAP): https://ataxia.io7m.com/2023/12/12/droid_12_hinting_nobitmaps.png That's already a lot better. If you overlay the two images in an image editor, it's clear that the glyph shapes are not quite the same (with hinting, some glyphs are ever-so-slightly taller). For completeness, let's allow bitmaps: https://ataxia.io7m.com/2023/12/12/droid_12_hinting_bitmaps.png The rendered glyphs are pixel-identical. Now, most modern desktops have options to disable antialiasing for text under a given size. Antialiasing on 10pt text is rarely an improvement over just not having it as there are so few pixels to work with. I decided to experiment a bit with turning off antialiasing. This requires setting the load target to FT_LOAD_TARGET_MONO so that Freetype returns a monochrome image instead of what amounts to an alpha coverage map. Unfortunately, this does also change the format of the image returned to a 1bpp image instead of an 8bpp greyscale image, and JavaFX isn't equipped to handle that. However, we can do the conversion manually if we see that bitmap.pixel_mode == 1, and then the rest of JavaFX doesn't need to care about it: ``` if (bitmap.pixel_mode == 1) { byte[] newBuffer = new byte[width * height]; for (int y = 0; y < height; y++) { final var rowOffset = y * width; for (int x = 0; x < width; x++) { final var byteOffset = rowOffset + x; newBuffer[byteOffset] = bitAt(buffer, x, y, pitch); } } buffer = newBuffer; } private static byte bitAt(byte[] buffer, int x, int y, int pitch) { final var byteOffset = (y * pitch) + (x / 8); final var bitOffset = 7 - (x % 8); final var bit = (buffer[byteOffset] >>> bitOffset) & 1; return (byte) (bit == 1 ? 0xff : 0x00); } ``` Here's the JavaFX default of (FT_LOAD_NO_HINTING | FT_LOAD_NO_BITMAP) combined with FT_LOAD_TARGET_MONO: https://ataxia.io7m.com/2023/12/12/droid_12_nohinting_nobitmaps_mono.png That's not a typeface even a mother could love. :) However, what happens if we enable hinting? Here's (FT_LOAD_NO_BITMAP | FT_LOAD_TARGET_MONO): https://ataxia.io7m.com/2023/12/12/droid_12_hinting_nobitmaps_mono.png I mean, it's not exactly wonderful for Droid Sans 12 (the O is a little mangled), but that's more an issue with the font itself. It's certainly better than the result _without_ hinting. Amusingly, here's DejaVu Sans at 7pt, (FT_LOAD_NO_BITMAP | FT_LOAD_TARGET_MONO): https://ataxia.io7m.com/2023/12/12/dejavu_12_hinting_nobitmaps_mono.png That, to my eyes, looks pretty good. The JavaFX defaults for the same font are not good: https://ataxia.io7m.com/2023/12/12/dejavu_12_nohinting_nobitmaps_normal.png I've tried on multiple systems (all Linux, however), and I've yet to be able to contrive a situation where the JavaFX defaults give better rendering results with any combinations of font sizes, with or without AA. A brief inspection of the JDK's Java2D sources show that it does conditionally use FT_LOAD_NO_HINTING depending on various settings (there are comments about FT_LOAD_NO_HINTING yielding constant-sized glyphs, which supposedly can make things easier in some cases). The Java2D results on the systems I tested are consistently better. So I guess my questions are: * Why do we discard hinting information? * Why do we discard bitmaps? * Would JavaFX accept patches to allow hinting, bitmaps, and FT_LOAD_TARGET_MONO? Ideally this should be developer-controlled, so I would need to come up with a pleasant API for it. My experience has been that most JavaFX applications tend to bundle fonts rather than relying on anything the system has. I suspect that, given that developers are including their own fonts, they are the best equipped to answer questions about hinting and AA, rather than just setting values and hoping that the font they get will work well, so an explicit API might be fine. -- Mark Raynsford | https://www.io7m.com From Florian.Kroiss at vector.com Tue Dec 12 14:28:24 2023 From: Florian.Kroiss at vector.com (=?iso-8859-1?Q?Kroi=DF=2C_Florian?=) Date: Tue, 12 Dec 2023 14:28:24 +0000 Subject: Unable to select row in TableView depending on stage height Message-ID: Hi everyone, there seems to be a bug where, depending on the current stage height, it is not possible to select a row in a TableView by clicking on it. There is an existing bug (https://bugs.openjdk.org/browse/JDK-8133697) which attributes this problem to maximizing the window, but I think it is more generally related to the stage height itself. Using the following code, I'm able to consistently reproduce the problem with JavaFX 21.0.1 on two different Windows 11 machines: package bug_report; import javafx.application.Application; import javafx.beans.property.SimpleStringProperty; import javafx.collections.FXCollections; import javafx.collections.ObservableList; import javafx.scene.Group; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.TableColumn; import javafx.scene.control.TableView; import javafx.scene.control.cell.PropertyValueFactory; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class Table extends Application { VBox root = new VBox(); private final TableView< Entry > table = new TableView<>(); private final ObservableList< Entry > data = FXCollections.observableArrayList(new Entry("A"), new Entry("B"), new Entry("C"), new Entry("D")); public static void main(final String[] args) { launch(args); } @Override public void start(final Stage stage) { Scene scene = new Scene(new Group()); final double weight = scene.getWidth(); final double height = scene.getHeight(); stage.setTitle("Table View Sample"); stage.setWidth(1000); stage.setHeight(1038); table.setEditable(true); final TableColumn< Entry, String > valueCol = new TableColumn<>("Value"); valueCol.setMinWidth(1000); valueCol.setCellValueFactory(new PropertyValueFactory< Entry, String >("value")); table.setItems(data); table.getColumns().add(valueCol); root.getChildren().addAll(table); final Button plus = new Button("+"); plus.setOnMouseClicked(evt -> { stage.setHeight(stage.getHeight() + 1); }); final Button minus = new Button("-"); minus.setOnMouseClicked(evt -> { stage.setHeight(stage.getHeight() - 1); }); root.getChildren().addAll(plus, minus); stage.heightProperty().addListener((obs, oldV, newV) -> { System.out.println("New height is: " + newV); }); scene = new Scene(root, weight, height, true); stage.setScene(scene); stage.show(); } public static class Entry { private final SimpleStringProperty value; private Entry( final String value ) { this.value = new SimpleStringProperty(value); } public SimpleStringProperty valueProperty() { return value; } } } Steps to reproduce: 1. Launch application 2. Use the "+" or "-" button to change the stage height 3. Try to select a different item in the TableView. If selection is still possible, go to step 2. Finding a stage height where this problem occurs seems to depend on the screen scale. With a scale of 100 % I can reproduce the issue with at least the following heights: 1018, 1022, 1038, 1042, 1044, 1045 I would be more than happy if someone could take a look at this problem. Best regards Florian Kroiss From thiago.sayao at gmail.com Tue Dec 12 16:03:50 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 12 Dec 2023 13:03:50 -0300 Subject: The crisp fonts saga In-Reply-To: References: Message-ID: Fonts started to look better on Ubuntu 23.04 https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6190 May be related to this change. Em ter., 12 de dez. de 2023 11:10, Mark Raynsford escreveu: > Hello! > > I've never been particularly satisfied with the font rendering in > JavaFX. In particular, on Linux, the text always appears very soft and > blurry compared to non-JavaFX applications on the same system. Even > applications that render antialiased text with Java2D seem to look > better. > > I decided to take a look into it to see if anything could be done about > this, and I have some questions. I'm only looking at the Freetype > implementation in Prism currently, as that's all I can realistically > test on at the moment. > > For reference, here's how text rendered at 16px using Terminus TTF > looks today: > > https://ataxia.io7m.com/2023/12/12/hinting_nobitmaps_normal.png > > I'm not sure if I'm alone on this, but I find this almost migraine- > inducing. No other application on my system, including those that use > Freetype, using that font at that size will render as blurry as that. > > Looking at > modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/FTFo > ntFile.java, I see this in initGlyph(): > > ``` > int flags = OSFreetype.FT_LOAD_RENDER | OSFreetype.FT_LOAD_NO_HINTING | > OSFreetype.FT_LOAD_NO_BITMAP; > ``` > > Additionally, the code might also add the FT_LOAD_TARGET_NORMAL > or FT_LOAD_TARGET_LCD flags later, but I'll assume > FT_LOAD_TARGET_NORMAL for the sake of avoiding combinatorial explosions > in testing at this point. > > Essentially, we discard hinting information, and we discard bitmap > information. I'm not sure why we do either of these things. I decided > to try different combinations of flags to see what would happen. > > Here's FT_LOAD_RENDER | FT_LOAD_NO_BITMAP (no bitmaps, but using > hinting data): > > https://ataxia.io7m.com/2023/12/12/hinting_nobitmaps_normal.png > > That's no real improvement. Here's FT_LOAD_RENDER | FT_LOAD_NO_HINTING > (ignore hinting data, but use bitmaps if they are included): > > https://ataxia.io7m.com/2023/12/12/nohinting_bitmaps_normal.png > > That, to my poor suffering eyes, is already a _vast_ improvement. > > Let's try including both hinting and bitmaps (FT_LOAD_RENDER): > > https://ataxia.io7m.com/2023/12/12/hinting_bitmaps_normal.png > > Inspecting that in an image editor shows the pixels of the text to be > identical. > > So, clearly, Terminus TTF includes bitmaps for smaller text sizes. > Let's try another font such as Droid Sans that renders crisply at ~10pt > sizes on my system, and that I'm reasonably confident doesn't include > any bitmaps. > > Here's the JavaFX default (FT_LOAD_NO_HINTING | FT_LOAD_NO_BITMAP): > > https://ataxia.io7m.com/2023/12/12/droid_12_nohinting_nobitmaps.png > > That's pretty nasty. Let's enable hinting (FT_LOAD_NO_BITMAP): > > https://ataxia.io7m.com/2023/12/12/droid_12_hinting_nobitmaps.png > > That's already a lot better. If you overlay the two images in an image > editor, it's clear that the glyph shapes are not quite the same (with > hinting, some glyphs are ever-so-slightly taller). > > For completeness, let's allow bitmaps: > > https://ataxia.io7m.com/2023/12/12/droid_12_hinting_bitmaps.png > > The rendered glyphs are pixel-identical. > > Now, most modern desktops have options to disable antialiasing for text > under a given size. Antialiasing on 10pt text is rarely an improvement > over just not having it as there are so few pixels to work with. I > decided to experiment a bit with turning off antialiasing. This > requires setting the load target to FT_LOAD_TARGET_MONO so that > Freetype returns a monochrome image instead of what amounts to an alpha > coverage map. Unfortunately, this does also change the format of the > image returned to a 1bpp image instead of an 8bpp greyscale image, and > JavaFX isn't equipped to handle that. However, we can do the conversion > manually if we see that bitmap.pixel_mode == 1, and then the rest of > JavaFX doesn't need to care about it: > > ``` > if (bitmap.pixel_mode == 1) { > byte[] newBuffer = new byte[width * height]; > for (int y = 0; y < height; y++) { > final var rowOffset = y * width; > for (int x = 0; x < width; x++) { > final var byteOffset = rowOffset + x; > newBuffer[byteOffset] = bitAt(buffer, x, y, pitch); > } > } > buffer = newBuffer; > } > > private static byte bitAt(byte[] buffer, int x, int y, int pitch) > { > final var byteOffset = (y * pitch) + (x / 8); > final var bitOffset = 7 - (x % 8); > final var bit = (buffer[byteOffset] >>> bitOffset) & 1; > return (byte) (bit == 1 ? 0xff : 0x00); > } > ``` > > Here's the JavaFX default of (FT_LOAD_NO_HINTING | FT_LOAD_NO_BITMAP) > combined with FT_LOAD_TARGET_MONO: > > https://ataxia.io7m.com/2023/12/12/droid_12_nohinting_nobitmaps_mono.png > > That's not a typeface even a mother could love. :) > > However, what happens if we enable hinting? > > Here's (FT_LOAD_NO_BITMAP | FT_LOAD_TARGET_MONO): > > https://ataxia.io7m.com/2023/12/12/droid_12_hinting_nobitmaps_mono.png > > I mean, it's not exactly wonderful for Droid Sans 12 (the O is a little > mangled), but that's more an issue with the font itself. It's certainly > better than the result _without_ hinting. > > Amusingly, here's DejaVu Sans at 7pt, (FT_LOAD_NO_BITMAP | > FT_LOAD_TARGET_MONO): > > https://ataxia.io7m.com/2023/12/12/dejavu_12_hinting_nobitmaps_mono.png > > That, to my eyes, looks pretty good. The JavaFX defaults for the same > font are not good: > > https://ataxia.io7m.com/2023/12/12/dejavu_12_nohinting_nobitmaps_normal.png > > I've tried on multiple systems (all Linux, however), and I've yet to be > able to contrive a situation where the JavaFX defaults give better > rendering results with any combinations of font sizes, with or without > AA. A brief inspection of the JDK's Java2D sources show that it does > conditionally use FT_LOAD_NO_HINTING depending on various settings > (there are comments about FT_LOAD_NO_HINTING yielding constant-sized > glyphs, which supposedly can make things easier in some cases). The > Java2D results on the systems I tested are consistently better. > > So I guess my questions are: > > * Why do we discard hinting information? > * Why do we discard bitmaps? > * Would JavaFX accept patches to allow hinting, bitmaps, and > FT_LOAD_TARGET_MONO? Ideally this should be developer-controlled, so I > would need to come up with a pleasant API for it. > > My experience has been that most JavaFX applications tend to bundle > fonts rather than relying on anything the system has. I suspect that, > given that developers are including their own fonts, they are the best > equipped to answer questions about hinting and AA, rather than just > setting values and hoping that the font they get will work well, so an > explicit API might be fine. > > -- > Mark Raynsford | https://www.io7m.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Dec 12 16:07:53 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 12 Dec 2023 16:07:53 +0000 Subject: Converting a Color object to its string representation In-Reply-To: <1BB9FE54-1C72-4B7A-9F45-E55C02DDAA54@gmail.com> References: <079901da2c77$85199e70$8f4cdb50$@leshem.life> <1BB9FE54-1C72-4B7A-9F45-E55C02DDAA54@gmail.com> Message-ID: I also think that the platform will benefit from adding this symmetrical API. It is less clear how that new API should deal with all the multiple variants of the web format (#rgb, #rrggbb, rgb, rgba, 0x*, ...). -andy From: openjfx-dev on behalf of Scott Palmer Date: Monday, December 11, 2023 at 17:12 To: openjfx-dev at openjdk.org Subject: Re: Converting a Color object to its string representation I agree. I was going to write pretty much this exact email, but you beat me to it. I was implementing some user-configurable colour customizations in an application and needed to do it with style sheets, along with something that reads colours along the lines of what the new platform preferences API does. I make a base64 data URL from a dynamically generated style sheet to avoid writing temp CSS files to style the app. I also needed to do this to work around the style sheet having higher priority than programmatically set colours as per my misunderstanding in https://bugs.openjdk.org/browse/JDK-8317434 So I see value in having Color implement something like this. Scott On Dec 11, 2023, at 4:19?PM, Eran Leshem wrote: ?Thank you for your responses. Given that the framework requires colors in string format in its style APIs, I think it should provide some way to convert colors to strings as expected by these APIs. Otherwise, clients are forced to implement this bridging logic on their own, due to a framework gap. And given that Color already parses these string representations, I think it makes sense for it to provide the inverse conversion. Eran -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-retn at openjdk.org] On Behalf Of John Hendrikx Sent: Saturday, December 09, 2023 11:35 PM To: openjfx-dev at openjdk.org Subject: Re: Converting a Color object to its string representation I think this is too niche to have Color provide. Just make a utility method for whatever format you desire, instead of making Color responsible for half a dozen ways of formatting colors, and then probably still missing some format that someone needs. Ticket should be closed as won't fix. --John On 09/12/2023 22:06, Michael Strau? wrote: I obviously meant to write withPrefix("#"), not withDelimiter("#")... On Sat, Dec 9, 2023 at 9:57?PM Michael Strau? wrote: How would HexFormat work with Color, other than using an extremely unwieldy syntax? String formatted = HexFormat.of() .withDelimiter("#") .formatHex(new byte[] { (byte)(color.getRed() * 255.0f), (byte)(color.getGreen() * 255.0f), (byte)(color.getBlue() * 255.0f), (byte)(color.getOpacity() * 255.0f) }); On Sat, Dec 9, 2023 at 9:40?PM David Alayachew wrote: Apologies - java.util.HexFormat That's what I get for firing from the hip, then looking afterwards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.sayao at gmail.com Tue Dec 12 16:11:38 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 12 Dec 2023 13:11:38 -0300 Subject: The crisp fonts saga In-Reply-To: References: Message-ID: The dates don't match since the change is from 4 months ago and 23.04 was released on April. So it was some other change. Em ter., 12 de dez. de 2023 13:03, Thiago Milczarek Say?o < thiago.sayao at gmail.com> escreveu: > Fonts started to look better on Ubuntu 23.04 > > https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6190 > > May be related to this change. > > Em ter., 12 de dez. de 2023 11:10, Mark Raynsford > escreveu: > >> Hello! >> >> I've never been particularly satisfied with the font rendering in >> JavaFX. In particular, on Linux, the text always appears very soft and >> blurry compared to non-JavaFX applications on the same system. Even >> applications that render antialiased text with Java2D seem to look >> better. >> >> I decided to take a look into it to see if anything could be done about >> this, and I have some questions. I'm only looking at the Freetype >> implementation in Prism currently, as that's all I can realistically >> test on at the moment. >> >> For reference, here's how text rendered at 16px using Terminus TTF >> looks today: >> >> https://ataxia.io7m.com/2023/12/12/hinting_nobitmaps_normal.png >> >> I'm not sure if I'm alone on this, but I find this almost migraine- >> inducing. No other application on my system, including those that use >> Freetype, using that font at that size will render as blurry as that. >> >> Looking at >> modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/FTFo >> ntFile.java, I see this in initGlyph(): >> >> ``` >> int flags = OSFreetype.FT_LOAD_RENDER | OSFreetype.FT_LOAD_NO_HINTING | >> OSFreetype.FT_LOAD_NO_BITMAP; >> ``` >> >> Additionally, the code might also add the FT_LOAD_TARGET_NORMAL >> or FT_LOAD_TARGET_LCD flags later, but I'll assume >> FT_LOAD_TARGET_NORMAL for the sake of avoiding combinatorial explosions >> in testing at this point. >> >> Essentially, we discard hinting information, and we discard bitmap >> information. I'm not sure why we do either of these things. I decided >> to try different combinations of flags to see what would happen. >> >> Here's FT_LOAD_RENDER | FT_LOAD_NO_BITMAP (no bitmaps, but using >> hinting data): >> >> https://ataxia.io7m.com/2023/12/12/hinting_nobitmaps_normal.png >> >> That's no real improvement. Here's FT_LOAD_RENDER | FT_LOAD_NO_HINTING >> (ignore hinting data, but use bitmaps if they are included): >> >> https://ataxia.io7m.com/2023/12/12/nohinting_bitmaps_normal.png >> >> That, to my poor suffering eyes, is already a _vast_ improvement. >> >> Let's try including both hinting and bitmaps (FT_LOAD_RENDER): >> >> https://ataxia.io7m.com/2023/12/12/hinting_bitmaps_normal.png >> >> Inspecting that in an image editor shows the pixels of the text to be >> identical. >> >> So, clearly, Terminus TTF includes bitmaps for smaller text sizes. >> Let's try another font such as Droid Sans that renders crisply at ~10pt >> sizes on my system, and that I'm reasonably confident doesn't include >> any bitmaps. >> >> Here's the JavaFX default (FT_LOAD_NO_HINTING | FT_LOAD_NO_BITMAP): >> >> https://ataxia.io7m.com/2023/12/12/droid_12_nohinting_nobitmaps.png >> >> That's pretty nasty. Let's enable hinting (FT_LOAD_NO_BITMAP): >> >> https://ataxia.io7m.com/2023/12/12/droid_12_hinting_nobitmaps.png >> >> That's already a lot better. If you overlay the two images in an image >> editor, it's clear that the glyph shapes are not quite the same (with >> hinting, some glyphs are ever-so-slightly taller). >> >> For completeness, let's allow bitmaps: >> >> https://ataxia.io7m.com/2023/12/12/droid_12_hinting_bitmaps.png >> >> The rendered glyphs are pixel-identical. >> >> Now, most modern desktops have options to disable antialiasing for text >> under a given size. Antialiasing on 10pt text is rarely an improvement >> over just not having it as there are so few pixels to work with. I >> decided to experiment a bit with turning off antialiasing. This >> requires setting the load target to FT_LOAD_TARGET_MONO so that >> Freetype returns a monochrome image instead of what amounts to an alpha >> coverage map. Unfortunately, this does also change the format of the >> image returned to a 1bpp image instead of an 8bpp greyscale image, and >> JavaFX isn't equipped to handle that. However, we can do the conversion >> manually if we see that bitmap.pixel_mode == 1, and then the rest of >> JavaFX doesn't need to care about it: >> >> ``` >> if (bitmap.pixel_mode == 1) { >> byte[] newBuffer = new byte[width * height]; >> for (int y = 0; y < height; y++) { >> final var rowOffset = y * width; >> for (int x = 0; x < width; x++) { >> final var byteOffset = rowOffset + x; >> newBuffer[byteOffset] = bitAt(buffer, x, y, pitch); >> } >> } >> buffer = newBuffer; >> } >> >> private static byte bitAt(byte[] buffer, int x, int y, int pitch) >> { >> final var byteOffset = (y * pitch) + (x / 8); >> final var bitOffset = 7 - (x % 8); >> final var bit = (buffer[byteOffset] >>> bitOffset) & 1; >> return (byte) (bit == 1 ? 0xff : 0x00); >> } >> ``` >> >> Here's the JavaFX default of (FT_LOAD_NO_HINTING | FT_LOAD_NO_BITMAP) >> combined with FT_LOAD_TARGET_MONO: >> >> https://ataxia.io7m.com/2023/12/12/droid_12_nohinting_nobitmaps_mono.png >> >> That's not a typeface even a mother could love. :) >> >> However, what happens if we enable hinting? >> >> Here's (FT_LOAD_NO_BITMAP | FT_LOAD_TARGET_MONO): >> >> https://ataxia.io7m.com/2023/12/12/droid_12_hinting_nobitmaps_mono.png >> >> I mean, it's not exactly wonderful for Droid Sans 12 (the O is a little >> mangled), but that's more an issue with the font itself. It's certainly >> better than the result _without_ hinting. >> >> Amusingly, here's DejaVu Sans at 7pt, (FT_LOAD_NO_BITMAP | >> FT_LOAD_TARGET_MONO): >> >> https://ataxia.io7m.com/2023/12/12/dejavu_12_hinting_nobitmaps_mono.png >> >> That, to my eyes, looks pretty good. The JavaFX defaults for the same >> font are not good: >> >> >> https://ataxia.io7m.com/2023/12/12/dejavu_12_nohinting_nobitmaps_normal.png >> >> I've tried on multiple systems (all Linux, however), and I've yet to be >> able to contrive a situation where the JavaFX defaults give better >> rendering results with any combinations of font sizes, with or without >> AA. A brief inspection of the JDK's Java2D sources show that it does >> conditionally use FT_LOAD_NO_HINTING depending on various settings >> (there are comments about FT_LOAD_NO_HINTING yielding constant-sized >> glyphs, which supposedly can make things easier in some cases). The >> Java2D results on the systems I tested are consistently better. >> >> So I guess my questions are: >> >> * Why do we discard hinting information? >> * Why do we discard bitmaps? >> * Would JavaFX accept patches to allow hinting, bitmaps, and >> FT_LOAD_TARGET_MONO? Ideally this should be developer-controlled, so I >> would need to come up with a pleasant API for it. >> >> My experience has been that most JavaFX applications tend to bundle >> fonts rather than relying on anything the system has. I suspect that, >> given that developers are including their own fonts, they are the best >> equipped to answer questions about hinting and AA, rather than just >> setting values and hoping that the font they get will work well, so an >> explicit API might be fine. >> >> -- >> Mark Raynsford | https://www.io7m.com >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Dec 12 17:03:51 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 12 Dec 2023 17:03:51 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v8] 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 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 27 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - tolerance - Merge remote-tracking branch 'origin/master' into 8299753.resize - undo merge - no new api - Merge remote-tracking branch 'origin/master' into 8299753.resize - cleanup - using snap inner space api - Merge remote-tracking branch 'origin/master' into 8299753.resize - ... and 17 more: https://git.openjdk.org/jfx/compare/8093b0d2...80286f26 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1156/files - new: https://git.openjdk.org/jfx/pull/1156/files/5e855022..80286f26 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=06-07 Stats: 53202 lines in 575 files changed: 24838 ins; 20459 del; 7905 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 duke at openjdk.org Tue Dec 12 17:09:43 2023 From: duke at openjdk.org (duke) Date: Tue, 12 Dec 2023 17:09:43 GMT Subject: Withdrawn: JDK-8290310: ChangeListener events are incorrect or misleading when a nested change occurs 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: On Tue, 4 Apr 2023 15:22:48 GMT, John Hendrikx wrote: > 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... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1081 From org.openjdk at io7m.com Tue Dec 12 17:34:01 2023 From: org.openjdk at io7m.com (Mark Raynsford) Date: Tue, 12 Dec 2023 17:34:01 +0000 Subject: The crisp fonts saga In-Reply-To: References: Message-ID: <2766692fc7b4e22012ae2e56063ac448acc1c4c9.camel@io7m.com> On Tue Dec 12 16:03:50 UTC 2023, Thiago Milczarek Say?o wrote: > Fonts started to look better on Ubuntu 23.04 > https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6190 > May be related to this change. Hello! To be clear: All the tests I performed were against the last "release" version of JavaFX on Central (21.0.1, which came out in 2023-10-17). I patched locally against the current `master` from the jfx repository, and the current `master` is definitely still discarding bitmaps and hinting: https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/FTFontFile.java#L133 The file actually hasn't been touched in 7 years! -- Mark Raynsford | https://www.io7m.com From angorya at openjdk.org Tue Dec 12 18:10:45 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 12 Dec 2023 18:10:45 GMT Subject: RFR: 8321902: Robot-based Behavior tests must be under test.robot hierarchy Message-ID: Robot system tests must be in test.robot.* package hierarchy because gradle. ------------- Commit messages: - 8321902: Robot-based Behavior tests must be under test.robot hierarchy Changes: https://git.openjdk.org/jfx/pull/1306/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1306&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321902 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1306.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1306/head:pull/1306 PR: https://git.openjdk.org/jfx/pull/1306 From philip.race at oracle.com Tue Dec 12 20:38:50 2023 From: philip.race at oracle.com (Philip Race) Date: Tue, 12 Dec 2023 12:38:50 -0800 Subject: The crisp fonts saga In-Reply-To: References: Message-ID: Usage of hinting in UIs is on the way out. macOS stopped applying hints ages ago. Apple also canned LCD text. High DPI displays are obsoleting the raison d'etre of both of these. A big problem with hinting is that it distorts both the size and the shape, so UIs do not scale evenly and animations look jerky. Another is that a poorly hinted font is far worse than no hinting at all. -phil. On 12/12/23 6:10 AM, Mark Raynsford wrote: > Hello! > > I've never been particularly satisfied with the font rendering in > JavaFX. In particular, on Linux, the text always appears very soft and > blurry compared to non-JavaFX applications on the same system. Even > applications that render antialiased text with Java2D seem to look > better. > > I decided to take a look into it to see if anything could be done about > this, and I have some questions. I'm only looking at the Freetype > implementation in Prism currently, as that's all I can realistically > test on at the moment. > > For reference, here's how text rendered at 16px using Terminus TTF > looks today: > > https://ataxia.io7m.com/2023/12/12/hinting_nobitmaps_normal.png > > I'm not sure if I'm alone on this, but I find this almost migraine- > inducing. No other application on my system, including those that use > Freetype, using that font at that size will render as blurry as that. > > Looking at > modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/FTFo > ntFile.java, I see this in initGlyph(): > > ``` > int flags = OSFreetype.FT_LOAD_RENDER | OSFreetype.FT_LOAD_NO_HINTING | > OSFreetype.FT_LOAD_NO_BITMAP; > ``` > > Additionally, the code might also add the FT_LOAD_TARGET_NORMAL > or FT_LOAD_TARGET_LCD flags later, but I'll assume > FT_LOAD_TARGET_NORMAL for the sake of avoiding combinatorial explosions > in testing at this point. > > Essentially, we discard hinting information, and we discard bitmap > information. I'm not sure why we do either of these things. I decided > to try different combinations of flags to see what would happen. > > Here's FT_LOAD_RENDER | FT_LOAD_NO_BITMAP (no bitmaps, but using > hinting data): > > https://ataxia.io7m.com/2023/12/12/hinting_nobitmaps_normal.png > > That's no real improvement. Here's FT_LOAD_RENDER | FT_LOAD_NO_HINTING > (ignore hinting data, but use bitmaps if they are included): > > https://ataxia.io7m.com/2023/12/12/nohinting_bitmaps_normal.png > > That, to my poor suffering eyes, is already a _vast_ improvement. > > Let's try including both hinting and bitmaps (FT_LOAD_RENDER): > > https://ataxia.io7m.com/2023/12/12/hinting_bitmaps_normal.png > > Inspecting that in an image editor shows the pixels of the text to be > identical. > > So, clearly, Terminus TTF includes bitmaps for smaller text sizes. > Let's try another font such as Droid Sans that renders crisply at ~10pt > sizes on my system, and that I'm reasonably confident doesn't include > any bitmaps. > > Here's the JavaFX default (FT_LOAD_NO_HINTING | FT_LOAD_NO_BITMAP): > > https://ataxia.io7m.com/2023/12/12/droid_12_nohinting_nobitmaps.png > > That's pretty nasty. Let's enable hinting (FT_LOAD_NO_BITMAP): > > https://ataxia.io7m.com/2023/12/12/droid_12_hinting_nobitmaps.png > > That's already a lot better. If you overlay the two images in an image > editor, it's clear that the glyph shapes are not quite the same (with > hinting, some glyphs are ever-so-slightly taller). > > For completeness, let's allow bitmaps: > > https://ataxia.io7m.com/2023/12/12/droid_12_hinting_bitmaps.png > > The rendered glyphs are pixel-identical. > > Now, most modern desktops have options to disable antialiasing for text > under a given size. Antialiasing on 10pt text is rarely an improvement > over just not having it as there are so few pixels to work with. I > decided to experiment a bit with turning off antialiasing. This > requires setting the load target to FT_LOAD_TARGET_MONO so that > Freetype returns a monochrome image instead of what amounts to an alpha > coverage map. Unfortunately, this does also change the format of the > image returned to a 1bpp image instead of an 8bpp greyscale image, and > JavaFX isn't equipped to handle that. However, we can do the conversion > manually if we see that bitmap.pixel_mode == 1, and then the rest of > JavaFX doesn't need to care about it: > > ``` > if (bitmap.pixel_mode == 1) { > byte[] newBuffer = new byte[width * height]; > for (int y = 0; y < height; y++) { > final var rowOffset = y * width; > for (int x = 0; x < width; x++) { > final var byteOffset = rowOffset + x; > newBuffer[byteOffset] = bitAt(buffer, x, y, pitch); > } > } > buffer = newBuffer; > } > > private static byte bitAt(byte[] buffer, int x, int y, int pitch) > { > final var byteOffset = (y * pitch) + (x / 8); > final var bitOffset = 7 - (x % 8); > final var bit = (buffer[byteOffset] >>> bitOffset) & 1; > return (byte) (bit == 1 ? 0xff : 0x00); > } > ``` > > Here's the JavaFX default of (FT_LOAD_NO_HINTING | FT_LOAD_NO_BITMAP) > combined with FT_LOAD_TARGET_MONO: > > https://ataxia.io7m.com/2023/12/12/droid_12_nohinting_nobitmaps_mono.png > > That's not a typeface even a mother could love. :) > > However, what happens if we enable hinting? > > Here's (FT_LOAD_NO_BITMAP | FT_LOAD_TARGET_MONO): > > https://ataxia.io7m.com/2023/12/12/droid_12_hinting_nobitmaps_mono.png > > I mean, it's not exactly wonderful for Droid Sans 12 (the O is a little > mangled), but that's more an issue with the font itself. It's certainly > better than the result _without_ hinting. > > Amusingly, here's DejaVu Sans at 7pt, (FT_LOAD_NO_BITMAP | > FT_LOAD_TARGET_MONO): > > https://ataxia.io7m.com/2023/12/12/dejavu_12_hinting_nobitmaps_mono.png > > That, to my eyes, looks pretty good. The JavaFX defaults for the same > font are not good: > > https://ataxia.io7m.com/2023/12/12/dejavu_12_nohinting_nobitmaps_normal.png > > I've tried on multiple systems (all Linux, however), and I've yet to be > able to contrive a situation where the JavaFX defaults give better > rendering results with any combinations of font sizes, with or without > AA. A brief inspection of the JDK's Java2D sources show that it does > conditionally use FT_LOAD_NO_HINTING depending on various settings > (there are comments about FT_LOAD_NO_HINTING yielding constant-sized > glyphs, which supposedly can make things easier in some cases). The > Java2D results on the systems I tested are consistently better. > > So I guess my questions are: > > * Why do we discard hinting information? > * Why do we discard bitmaps? > * Would JavaFX accept patches to allow hinting, bitmaps, and > FT_LOAD_TARGET_MONO? Ideally this should be developer-controlled, so I > would need to come up with a pleasant API for it. > > My experience has been that most JavaFX applications tend to bundle > fonts rather than relying on anything the system has. I suspect that, > given that developers are including their own fonts, they are the best > equipped to answer questions about hinting and AA, rather than just > setting values and hoping that the font they get will work well, so an > explicit API might be fine. > From kcr at openjdk.org Tue Dec 12 20:42:34 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 12 Dec 2023 20:42:34 GMT Subject: RFR: 8321902: Robot-based Behavior tests must be under test.robot hierarchy In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 17:16:44 GMT, Andy Goryachev wrote: > Robot system tests must be in test.robot.* package hierarchy because gradle. Looks good. I confirm that after this fix, the tests are only run when `USE_ROBOT` is `true` ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1306#pullrequestreview-1778398974 From angorya at openjdk.org Tue Dec 12 20:50:33 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 12 Dec 2023 20:50:33 GMT Subject: Integrated: 8321902: Robot-based Behavior tests must be under test.robot hierarchy In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 17:16:44 GMT, Andy Goryachev wrote: > Robot system tests must be in test.robot.* package hierarchy because gradle. This pull request has now been integrated. Changeset: 8872f7af Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/8872f7afab5eca725b29d9e5b005084c22b27b9c Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod 8321902: Robot-based Behavior tests must be under test.robot hierarchy Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1306 From eran at leshem.life Wed Dec 13 00:04:47 2023 From: eran at leshem.life (Eran Leshem) Date: Wed, 13 Dec 2023 02:04:47 +0200 Subject: Converting a Color object to its string representation In-Reply-To: References: <079901da2c77$85199e70$8f4cdb50$@leshem.life> <1BB9FE54-1C72-4B7A-9F45-E55C02DDAA54@gmail.com> Message-ID: <006501da2d57$fd6350c0$f829f240$@leshem.life> I can see two options: 1. Minimal, just in order to satisfy the style APIs need ? supporting a single format. I would go with non-% rgba, since it covers all dimensions in the most straightforward way. 2. Complete ? supporting all formats accepted by Color.web(), either via multiple methods or via an enum parameter Eran From: openjfx-dev [mailto:openjfx-dev-retn at openjdk.org] On Behalf Of Andy Goryachev Sent: Tuesday, December 12, 2023 6:08 PM To: Scott Palmer; openjfx-dev at openjdk.org Subject: Re: Converting a Color object to its string representation I also think that the platform will benefit from adding this symmetrical API. It is less clear how that new API should deal with all the multiple variants of the web format (#rgb, #rrggbb, rgb, rgba, 0x*, ...). -andy From: openjfx-dev on behalf of Scott Palmer Date: Monday, December 11, 2023 at 17:12 To: openjfx-dev at openjdk.org Subject: Re: Converting a Color object to its string representation I agree. I was going to write pretty much this exact email, but you beat me to it. I was implementing some user-configurable colour customizations in an application and needed to do it with style sheets, along with something that reads colours along the lines of what the new platform preferences API does. I make a base64 data URL from a dynamically generated style sheet to avoid writing temp CSS files to style the app. I also needed to do this to work around the style sheet having higher priority than programmatically set colours as per my misunderstanding in https://bugs.openjdk.org/browse/JDK-8317434 So I see value in having Color implement something like this. Scott On Dec 11, 2023, at 4:19?PM, Eran Leshem wrote: ?Thank you for your responses. Given that the framework requires colors in string format in its style APIs, I think it should provide some way to convert colors to strings as expected by these APIs. Otherwise, clients are forced to implement this bridging logic on their own, due to a framework gap. And given that Color already parses these string representations, I think it makes sense for it to provide the inverse conversion. Eran -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-retn at openjdk.org] On Behalf Of John Hendrikx Sent: Saturday, December 09, 2023 11:35 PM To: openjfx-dev at openjdk.org Subject: Re: Converting a Color object to its string representation I think this is too niche to have Color provide. Just make a utility method for whatever format you desire, instead of making Color responsible for half a dozen ways of formatting colors, and then probably still missing some format that someone needs. Ticket should be closed as won't fix. --John On 09/12/2023 22:06, Michael Strau? wrote: I obviously meant to write withPrefix("#"), not withDelimiter("#")... On Sat, Dec 9, 2023 at 9:57?PM Michael Strau? wrote: How would HexFormat work with Color, other than using an extremely unwieldy syntax? String formatted = HexFormat.of() .withDelimiter("#") .formatHex(new byte[] { (byte)(color.getRed() * 255.0f), (byte)(color.getGreen() * 255.0f), (byte)(color.getBlue() * 255.0f), (byte)(color.getOpacity() * 255.0f) }); On Sat, Dec 9, 2023 at 9:40?PM David Alayachew wrote: Apologies - java.util.HexFormat That's what I get for firing from the hip, then looking afterwards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpereda at openjdk.org Wed Dec 13 09:16:55 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 13 Dec 2023 09:16:55 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v2] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 08:00:58 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > process reviewers comments modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java line 189: > 187: > 188: private ListChangeListener createListener(final Menu glassMenu) { > 189: return (ListChangeListener.Change change) -> { In this listener, when there are items removed that are `Menu`s, we should also call `clearMenu`: if (i >= 0 && menuItemList.size() > i) { glassMenu.remove(i); + Object item = menuItemList.get(i); + if (item instanceof Menu menu) { + clearMenu(menu); + } } Otherwise, they won't be removed from the new maps. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1425062079 From jpereda at openjdk.org Wed Dec 13 09:22:50 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 13 Dec 2023 09:22:50 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v2] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 08:00:58 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > process reviewers comments About adding an automated test, the leak that PR tries to fix happens in `com.sun.javafx.tk.quantum.GlassSystemMenu`, which is package private, and adding new tests to check `javafx.scene.control.Menu`, or related public classes, won't catch that leak, will it? Unless we open it (and all the related classes/methods in `com.sun.glass.ui.*`), I don't think it can be done? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1853543288 From org.openjdk at io7m.com Wed Dec 13 11:29:26 2023 From: org.openjdk at io7m.com (Mark Raynsford) Date: Wed, 13 Dec 2023 11:29:26 +0000 Subject: The crisp fonts saga In-Reply-To: References: Message-ID: <6fe35492269e4e682d6ee6218fa0271a0fd61217.camel@io7m.com> On Tue, 2023-12-12 at 12:38 -0800, Philip Race wrote: > Usage of hinting in UIs is on the way out. > macOS stopped applying hints ages ago. Apple also canned LCD text. > High DPI displays are obsoleting the raison d'etre of both of these. High DPI displays might be the future, but they're not the present yet and the numbers don't support the idea that the market is changing all that much. Looking at the numbers that exist, the standard 1080p display is still a significant portion of the marketplace: https://gs.statcounter.com/screen-resolution-stats/desktop/worldwide I would love to live in a world where everyone has such a high resolution display that we can turn off AA entirely, but we don't live in that one yet. > A big problem with hinting is that it distorts both the size and the > shape, so UIs do not scale evenly Can you give an example of UIs scaling unevenly, or animations looking jerky? All other non-JavaFX UI applications on my system evidently use hinting, and I don't see anything recognizable there. I'm unclear on how this could affect scaling given that glyphs are rendered once and then stuck into a texture atlas on the GPU; a glyph rendered without hinting is going to be just as static as a glyph rendered with hinting, except that the glyph rendered with hinting is going to look "better" (assuming non-broken hinting in the font file). Do you mean that the glyphs are continuously regenerated during some kind of scaling animation operation? > Another is that a poorly hinted font is far worse than no hinting at all. Which should be decided on a font-by-font basis, which I think the developer bundling the font is best equipped to make decisions about. -- Mark Raynsford | https://www.io7m.com From kevin.rushforth at oracle.com Wed Dec 13 12:45:59 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 13 Dec 2023 04:45:59 -0800 Subject: Converting a Color object to its string representation In-Reply-To: <006501da2d57$fd6350c0$f829f240$@leshem.life> References: <079901da2c77$85199e70$8f4cdb50$@leshem.life> <1BB9FE54-1C72-4B7A-9F45-E55C02DDAA54@gmail.com> <006501da2d57$fd6350c0$f829f240$@leshem.life> Message-ID: <02d77b6d-8646-446f-9cee-126fd3434a8c@oracle.com> Or the third option: 3. Do nothing I would go for option 1 or 3. I do not recommend option 2. I see some value in a minimal API (option 1), returning a fixed format, perhaps: ??? if alpha == 1 { "#rrggbb" } else { "#rrggbbaa" } -- Kevin On 12/12/2023 4:04 PM, Eran Leshem wrote: > > I can see two options: > > 1.Minimal, just in order to satisfy the style APIs need ? supporting a > single format. I would go with non-% rgba, since it covers all > dimensions in the most straightforward way. > > 2.Complete ? supporting all formats accepted by Color.web(), either > via multiple methods or via an enum parameter > > Eran > > *From:*openjfx-dev [mailto:openjfx-dev-retn at openjdk.org] *On Behalf Of > *Andy Goryachev > *Sent:* Tuesday, December 12, 2023 6:08 PM > *To:* Scott Palmer; openjfx-dev at openjdk.org > *Subject:* Re: Converting a Color object to its string representation > > I also think that the platform will benefit from adding this > symmetrical API. > > It is less clear how that new API should deal with all the multiple > variants of the web format (#rgb, #rrggbb, rgb, rgba, 0x*, ...). > > -andy > > *From: *openjfx-dev on behalf of Scott > Palmer > *Date: *Monday, December 11, 2023 at 17:12 > *To: *openjfx-dev at openjdk.org > *Subject: *Re: Converting a Color object to its string representation > > I agree. I was going to write pretty much this exact email, but you > beat me to it. > > I was implementing some user-configurable colour customizations in an > application and needed to do it with style sheets, along with > something that reads colours along the lines of what the new platform > preferences API does. > > I make a base64 data URL from a dynamically generated style sheet to > avoid writing temp CSS files to style the app. > > I also needed to do this to work around the style sheet having higher > priority than programmatically set colours as per my misunderstanding > in https://bugs.openjdk.org/browse/JDK-8317434 > > So I see value in having Color implement something like this. > > Scott > > On Dec 11, 2023, at 4:19?PM, Eran Leshem wrote: > > ?Thank you for your responses. > > Given that the framework requires colors in string format in its > style APIs, I think it should provide some way to convert colors > to strings as expected by these APIs. Otherwise, clients are > forced to implement this bridging logic on their own, due to a > framework gap. > > And given that Color already parses these string representations, > I think it makes sense for it to provide the inverse conversion. > > Eran > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-retn at openjdk.org] On Behalf > Of John Hendrikx > Sent: Saturday, December 09, 2023 11:35 PM > To: openjfx-dev at openjdk.org > Subject: Re: Converting a Color object to its string representation > > I think this is too niche to have Color provide. > > Just make a utility method for whatever format you desire, instead of > making Color responsible for half a dozen ways of formatting > colors, and > then probably still missing some format that someone needs. > > Ticket should be closed as won't fix. > > --John > > On 09/12/2023 22:06, Michael Strau? wrote: > > I obviously meant to write withPrefix("#"), not > withDelimiter("#")... > > On Sat, Dec 9, 2023 at 9:57?PM Michael Strau? > wrote: > > How would HexFormat work with Color, other than using an > extremely > > unwieldy syntax? > > ????String formatted = HexFormat.of() > > ????????.withDelimiter("#") > > ????????.formatHex(new byte[] { > > ????????????(byte)(color.getRed() * 255.0f), > > ????????????(byte)(color.getGreen() * 255.0f), > > ????????????(byte)(color.getBlue() * 255.0f), > > ????????????(byte)(color.getOpacity() * 255.0f) > > ????????}); > > On Sat, Dec 9, 2023 at 9:40?PM David Alayachew > wrote: > > Apologies - java.util.HexFormat > > That's what I get for firing from the hip, then > looking afterwards. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Wed Dec 13 16:16:12 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 13 Dec 2023 16:16:12 +0000 Subject: Unable to select row in TableView depending on stage height In-Reply-To: References: Message-ID: It seems the problem might be related to using a Scene with depthBuffer = true. Set it to false (or use a different constructor) and the problem goes away. Still, this looks like a bug. Created https://bugs.openjdk.org/browse/JDK-8322002 -andy From: openjfx-dev on behalf of Kroi?, Florian Date: Tuesday, December 12, 2023 at 06:28 To: openjfx-dev at openjdk.org Subject: Unable to select row in TableView depending on stage height Hi everyone, there seems to be a bug where, depending on the current stage height, it is not possible to select a row in a TableView by clicking on it. There is an existing bug (https://bugs.openjdk.org/browse/JDK-8133697) which attributes this problem to maximizing the window, but I think it is more generally related to the stage height itself. Using the following code, I'm able to consistently reproduce the problem with JavaFX 21.0.1 on two different Windows 11 machines: package bug_report; import javafx.application.Application; import javafx.beans.property.SimpleStringProperty; import javafx.collections.FXCollections; import javafx.collections.ObservableList; import javafx.scene.Group; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.TableColumn; import javafx.scene.control.TableView; import javafx.scene.control.cell.PropertyValueFactory; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class Table extends Application { VBox root = new VBox(); private final TableView< Entry > table = new TableView<>(); private final ObservableList< Entry > data = FXCollections.observableArrayList(new Entry("A"), new Entry("B"), new Entry("C"), new Entry("D")); public static void main(final String[] args) { launch(args); } @Override public void start(final Stage stage) { Scene scene = new Scene(new Group()); final double weight = scene.getWidth(); final double height = scene.getHeight(); stage.setTitle("Table View Sample"); stage.setWidth(1000); stage.setHeight(1038); table.setEditable(true); final TableColumn< Entry, String > valueCol = new TableColumn<>("Value"); valueCol.setMinWidth(1000); valueCol.setCellValueFactory(new PropertyValueFactory< Entry, String >("value")); table.setItems(data); table.getColumns().add(valueCol); root.getChildren().addAll(table); final Button plus = new Button("+"); plus.setOnMouseClicked(evt -> { stage.setHeight(stage.getHeight() + 1); }); final Button minus = new Button("-"); minus.setOnMouseClicked(evt -> { stage.setHeight(stage.getHeight() - 1); }); root.getChildren().addAll(plus, minus); stage.heightProperty().addListener((obs, oldV, newV) -> { System.out.println("New height is: " + newV); }); scene = new Scene(root, weight, height, true); stage.setScene(scene); stage.show(); } public static class Entry { private final SimpleStringProperty value; private Entry( final String value ) { this.value = new SimpleStringProperty(value); } public SimpleStringProperty valueProperty() { return value; } } } Steps to reproduce: 1. Launch application 2. Use the "+" or "-" button to change the stage height 3. Try to select a different item in the TableView. If selection is still possible, go to step 2. Finding a stage height where this problem occurs seems to depend on the screen scale. With a scale of 100 % I can reproduce the issue with at least the following heights: 1018, 1022, 1038, 1042, 1044, 1045 I would be more than happy if someone could take a look at this problem. Best regards Florian Kroiss -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfox at openjdk.org Wed Dec 13 19:41:02 2023 From: mfox at openjdk.org (Martin Fox) Date: Wed, 13 Dec 2023 19:41:02 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v13] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 22:09:37 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Account the case of !filtered This PR is a massive simplification of the code and brings JavaFX in line with the behavior of other Linux apps. The complication is the introduction of scene-relative caret positioning. I understand Wayland is forcing the issue by ditching screen coordinates but I'm not sure this is the PR to start tackling that. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java line 681: > 679: public double[] getInputMethodCandidateRelativePos(int offset) { > 680: Point2D p2d = scene.inputMethodRequests.getTextLocationRelative(offset); > 681: return new double[] { p2d.getX(), p2d.getY() }; On my system the IM window is incorrectly positioned. This appears to be because I'm running a high-DPI display with 200% magnification. I think you need to call getPlatformScaleX and getPlatformScaleY and apply those scaling factors before passing these coordinates on to glass. You'll see other places in this file where conversions like that are being performed. modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 486: > 484: CHECK_JNI_EXCEPTION(mainEnv) > 485: > 486: if (press && key > 0) { // TYPED events should only be sent for printable characters. A handler for the PRESS event might close the window. In that case `jview` will be set to zero before you send out the TYPED event. You should do another check for that here. See [JDK-8301219](https://bugs.openjdk.org/browse/JDK-8301219) for some sample code. I'll be submitting a fix for that bug just as soon as I get a test case working reliably. modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 67: > 65: } while (pango_attr_iterator_next(iter)); > 66: > 67: pango_attr_iterator_destroy (iter); According to the docs you need to release the attribute list using pango_attr_list_unref(). modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 120: > 118: if (!filtered || (filtered && im_ctx.send_keypress)) { > 119: process_key(&event->key); > 120: im_ctx.send_keypress = false; I'm seeing two RELEASE events on each keystroke. If you call process_key() here you need to set `filtered` to true to ensure the event isn't processed again. modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 175: > 173: if (im_ctx.ctx != NULL) { > 174: g_signal_handlers_disconnect_matched(im_ctx.ctx, G_SIGNAL_MATCH_DATA, 0, 0, NULL, NULL, NULL); > 175: g_object_unref(im_ctx.ctx); If the IM window is visible when the window is closed disableIME() can get called twice; I'm seeing debug output being generated. Set im_ctx.ctx to NULL here or you'll unref it twice. ------------- Changes requested by mfox (Committer). PR Review: https://git.openjdk.org/jfx/pull/1080#pullrequestreview-1780301464 PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1425768173 PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1425788182 PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1425774627 PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1425775953 PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1425777541 From mfox at openjdk.org Thu Dec 14 01:05:14 2023 From: mfox at openjdk.org (Martin Fox) Date: Thu, 14 Dec 2023 01:05:14 GMT Subject: RFR: 8301219: JavaFX crash when closing with the escape key Message-ID: While processing a key down event the Glass GTK code sends out PRESSED and TYPED KeyEvents back to back. If the stage is closed during the PRESSED event the code will end up referencing freed memory while sending out the TYPED event. This can lead to intermittent crashes. In GlassApplication.cpp the EventCounterHelper object ensures the WindowContext isn't deleted while processing an event. Currently the helper object is being created *after* IME handling instead of before. If the IME is enabled it's possible for the WindowContext to be deleted in the middle of executing a number of keyboard-related events. The fix is simple; instantiate the EventCounterHelper object earlier. There isn't always a WindowContext so I tweaked the EventCounterHelper to do nothing if the context is null. To make the crash more reproducible I altered the WindowContext such that when it's deleted the freed memory is filled with 0xCC. This made the crash more reproducible and allowed me to test the fix. I did the same with GlassView since that's the only other Glass GTK class that's instantiated with `new` and discarded with `delete`. ------------- Commit messages: - Minor cleanup. - Version of test that succeeds on Windows - WindowContext is no longer deleted in the middle of processing a key event Changes: https://git.openjdk.org/jfx/pull/1307/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1307&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301219 Stats: 197 lines in 5 files changed: 188 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1307.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1307/head:pull/1307 PR: https://git.openjdk.org/jfx/pull/1307 From john at status6.com Thu Dec 14 06:15:09 2023 From: john at status6.com (John Neffenger) Date: Wed, 13 Dec 2023 22:15:09 -0800 Subject: The crisp fonts saga In-Reply-To: <6fe35492269e4e682d6ee6218fa0271a0fd61217.camel@io7m.com> References: <6fe35492269e4e682d6ee6218fa0271a0fd61217.camel@io7m.com> Message-ID: <62ab26d6-33ef-4b0b-b016-4140901939a5@status6.com> On 12/13/23 3:29 AM, Mark Raynsford wrote: > I would love to live in a world where everyone has such a high > resolution display that we can turn off AA entirely, but we don't live > in that one yet. Anti-aliasing is still widely in use, but the various operating systems and application frameworks have diverged in their policies on hinting and sub-pixel rendering. I find it helps to get the bigger picture. Below are the various camps as I've come to understand them over the years. Full hinting and sub-pixel rendering: - Microsoft Windows - Java Swing Slight hinting and sub-pixel rendering: - Ubuntu for sure - probably Debian, Fedora, Red Hat, and others, too No hinting, but with sub-pixel rendering: - JavaFX No hinting, and also no sub-pixel rendering: - Apple macOS (uses traditional grayscale anti-aliasing) I think that's why historically Windows users thought macOS (and JavaFX) fonts were too "blurry," and macOS users thought Windows fonts were too "jagged." It all depended on what you were used to. In my opinion, Linux distributions like Ubuntu got it right by going with "slight" hinting by default (FT_LOAD_TARGET_LIGHT). Even the Freetype developers think that's the right choice. Their reasons are given in this rather technical article, with an excerpt below: On Slight Hinting, Proper Text Rendering, Stem Darkening and LCD Filters https://freetype.org/freetype2/docs/hinting/text-rendering-general.html "I also hope this change will make it easier for the non-Windows-and-Apple ecosystem to switch over to slight hinting as the default. Current full/medium native hinting, as is the default, tends to bring out the worst in many, many fonts that haven?t seen the same insane dedication to on-screen display and hinting as many popular Microsoft fonts, for example. And since ClearType is still not fully supported, you usually get a very poor default experience. Slight hinting gives a much better one, as Ubuntu has proven over the years." > Can you give an example of UIs scaling unevenly, or animations looking > jerky? All other non-JavaFX UI applications on my system evidently use > hinting, and I don't see anything recognizable there. There are some text animations in JavaFX that you won't see in most user interfaces: think text rotations, not stock tickers. It's difficult to keep text aligned to the pixel grid when the grid is rotating. I would love to hear the full history of this choice in JavaFX. I agree that no hinting is a good choice now, but it was brave all those years ago when most people were on fully-hinted Windows. Did it really come down to its detrimental effect on animated text? John From john.hendrikx at gmail.com Thu Dec 14 09:23:59 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 14 Dec 2023 10:23:59 +0100 Subject: The crisp fonts saga In-Reply-To: <62ab26d6-33ef-4b0b-b016-4140901939a5@status6.com> References: <6fe35492269e4e682d6ee6218fa0271a0fd61217.camel@io7m.com> <62ab26d6-33ef-4b0b-b016-4140901939a5@status6.com> Message-ID: On 14/12/2023 07:15, John Neffenger wrote: > On 12/13/23 3:29 AM, Mark Raynsford wrote: > >> Can you give an example of UIs scaling unevenly, or animations looking >> jerky? All other non-JavaFX UI applications on my system evidently use >> hinting, and I don't see anything recognizable there. > > There are some text animations in JavaFX that you won't see in most > user interfaces: think text rotations, not stock tickers. It's > difficult to keep text aligned to the pixel grid when the grid is > rotating. Animated text is extremely rare in productivity applications, so I think this really should be an option on a Node by Node basis (there is already the cache/cacheHint property which are animation related). A big wall of text (like in a rich text control, TextArea or some kind of text editor) shouldn't have to suffer in readability just in case we may want to rotate or scale it... If Browsers had the JavaFX mentality of font rendering, everyone would switch to the one browser that renders font properly -- and I can imagine poorly rendered text is one the first things people notice and can be a big reason for worse JavaFX adoption. Also, if the animation is fast enough (ie,? a quick rotate / scale / translate transition) you won't notice any odd effects on the text scaling.? I can imagine it will look terrible though if you slow those down (ie. a transition taking a couple of seconds -- a bit unrealistic for a usable application though). --John From org.openjdk at io7m.com Thu Dec 14 12:15:43 2023 From: org.openjdk at io7m.com (Mark Raynsford) Date: Thu, 14 Dec 2023 12:15:43 +0000 Subject: The crisp fonts saga In-Reply-To: References: <6fe35492269e4e682d6ee6218fa0271a0fd61217.camel@io7m.com> <62ab26d6-33ef-4b0b-b016-4140901939a5@status6.com> Message-ID: <8662f6e66ff32a8952c25e51e5d4db6963667e70.camel@io7m.com> On Thu, 2023-12-14 at 10:23 +0100, John Hendrikx wrote: > > Animated text is extremely rare in productivity applications, so I > think > this really should be an option on a Node by Node basis (there is > already the cache/cacheHint property which are animation related). A > big > wall of text (like in a rich text control, TextArea or some kind of > text > editor) shouldn't have to suffer in readability just in case we may > want > to rotate or scale it... If Browsers had the JavaFX mentality of font > rendering, everyone would switch to the one browser that renders font > properly -- and I can imagine poorly rendered text is one the first > things people notice and can be a big reason for worse JavaFX > adoption. I agree strongly. Purely anecdotally, and obviously I'm only a single sample point (although there are two more lower down!): I started out as a classic Mac user back in the early days of Mac OS 7. I migrated to Windows 2000 and Linux, and have primarily been a Linux user and to a drastically lesser extent a Windows user for my entire career. I mention this because I want to make it clear that I'm not biased towards any particular style of text rendering. I've worked on GTK, QT, and FLTK applications. Some small-scale Cocoa applications when Mac OS X first appeared. I've written Windows applications in the Win32 days. I've written Swing applications. All of these have been used by others to varying degrees. What's the _one_ platform where users complained about the text? JavaFX. Worst is that there's really nothing I can tell them... "Sorry the text is awful, the UI library I used has made the decision for me and won't allow me to change it." It's essentially my only complaint with JavaFX. In all other respects, it's better than every other UI library I've ever used. -- Mark Raynsford | https://www.io7m.com From org.openjdk at io7m.com Thu Dec 14 12:39:23 2023 From: org.openjdk at io7m.com (Mark Raynsford) Date: Thu, 14 Dec 2023 12:39:23 +0000 Subject: The crisp fonts saga In-Reply-To: <62ab26d6-33ef-4b0b-b016-4140901939a5@status6.com> References: <6fe35492269e4e682d6ee6218fa0271a0fd61217.camel@io7m.com> <62ab26d6-33ef-4b0b-b016-4140901939a5@status6.com> Message-ID: On Wed, 2023-12-13 at 22:15 -0800, John Neffenger wrote: > > There are some text animations in JavaFX that you won't see in most > user > interfaces: think text rotations, not stock tickers. It's difficult > to > keep text aligned to the pixel grid when the grid is rotating. I don't buy this argument, having looked at the implementation. The key point is "keep text aligned to the pixel grid". The thing is: This isn't affected by hinting or the lack of it whatsoever, at least with the way text is implemented in Prism and Freetype, as far as I can tell. In the Prism/Freetype implementation, when the user wants to render the string "Hello World!", for each character in the string, a glyph is requested from Freetype. The contents of the returned glyph bitmap are packed into a persistent texture atlas on the GPU (the "glyph cache"). When actually rendering the string in the UI, the system constructs a set of polygons where each polygon represents one glyph, and each polygon is textured by having its UV coordinates mapped to the corresponding region of the glyph cache for the glyph. What this means is that it's entirely irrelevant whether hinting is used to produce the original glyph bitmap or not: The hinting just controls what pixels come out of Freetype before being written into the glyph cache. The system blindly selects a region of pixels from the glyph cache to be mapped onto polygons; it doesn't even know if those pixels were produced by a text rendering algorithm that used hinting or not. This argument _might_ apply if text was being directly software rendered to the screen, and the entire text was being re-rendered as full strings aligned to a screen-sized pixel grid every time. I could see in that case that an algorithm might produce output that varied on a frame-to-frame basis dependent on hinting. That's not the case here, though. Case in point: I've worked with a lot of OpenGL applications that do text rendering the same way, all of which used hinting, and all of which did heavy rotation and scaling of the resulting text as part of animations. Noone ever complained about jerky or weird text. In fact, most rendering engines these days don't even bother rendering text on a per-glyph basis; they just tell Freetype (or text library of choice) to render a full string into an image, with hinting, and that image is uploaded directly onto the GPU and displayed as a single textured polygon. Additionally, there are also techniques devoted to preserving sharpness?and reducing other artifacts in the face of rotations. They're known as "fat pixel" shaders, and are trivial to implement: https://jorenjoestar.github.io/post/pixel_art_filtering/ They're usually discussed in the context of pixel art, but they work very well with text rendering too for the same reasons. -- Mark Raynsford | https://www.io7m.com From kcr at openjdk.org Thu Dec 14 17:12:57 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Dec 2023 17:12:57 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 11:19:23 GMT, Jose Pereda wrote: > This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. We want the ability to build this on a system that may or may not have GTK 3.20, and then to have the binary produced by the build be able to run on a system that may or may not have GTK 3.20, using the new function if available. This means that there should not be any compile-time `#if` checks. All checks should be runtime checks, for example, checking whether or not the function pointer obtained via dlsym is NULL vs non-NULL. I think you already have the needed runtime checks. I was able to compile your PR branch, using headers and libraries from GTK > 3.20, and run it on a system with GTK < 3.20. I confirmed that the dlsym returned NULL on that system (as expected), and it didn't crash. So it might be as simple as removing the `#if` checks along with the entire "else" blocks, letting the code currently in the `#if` checks be unconditionally compiled. As long as you aren't using anything from a system GTK header file that doesn't exist in 3.8, this should be fine. modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp line 599: > 597: return TRUE; > 598: } > 599: #if GTK_CHECK_VERSION(3, 20, 0) I wouldn't have expected any compile-time `#if` checks as part of this PR. ------------- PR Review: https://git.openjdk.org/jfx/pull/1305#pullrequestreview-1782152507 PR Review Comment: https://git.openjdk.org/jfx/pull/1305#discussion_r1426923806 From john at status6.com Thu Dec 14 18:01:18 2023 From: john at status6.com (John Neffenger) Date: Thu, 14 Dec 2023 10:01:18 -0800 Subject: The crisp fonts saga In-Reply-To: References: Message-ID: On 12/12/23 6:10 AM, Mark Raynsford wrote: > I've never been particularly satisfied with the font rendering in > JavaFX. In particular, on Linux, the text always appears very soft and > blurry compared to non-JavaFX applications on the same system. Here's the best source I've found for the history of JavaFX text rendering. It's a presentation by Felipe Heidrich who worked on the implementation and now works at Google. JavaFX Text Rendering https://www.youtube.com/watch?v=LCrCni6EVek It's frustratingly short on details about the specific decision not to use hinting on Linux, but you can hear his opinions on the matter. In particular, see the following sections: Text Rendering Options https://www.youtube.com/watch?v=LCrCni6EVek&t=911 Hinting https://www.youtube.com/watch?v=LCrCni6EVek&t=1607 Linux https://www.youtube.com/watch?v=LCrCni6EVek&t=2716 In this part he says only, "Another thing you can do in Freetype, you can tell it not to hint." My main point in my previous message was that, in the unlikely event that we were to apply hinting in JavaFX on Linux, I would hope that we use the "slight" hinting that is recommended by Freetype. That snaps to the pixel grid only vertically, preserving the inter-glyph spacing of horizontal text. Kevin and Phil, were you working with Felipe when these text rendering decisions were made almost 10 years ago? Do you recall any background information on the design choices? Thanks, John From jpereda at openjdk.org Thu Dec 14 20:15:54 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 14 Dec 2023 20:15:54 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 16:02:48 GMT, Kevin Rushforth wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp line 599: > >> 597: return TRUE; >> 598: } >> 599: #if GTK_CHECK_VERSION(3, 20, 0) > > I wouldn't have expected any compile-time `#if` checks as part of this PR. Okay, that makes sense. I've removed the compile-time `#if-#else` from `wrapped.c`. However, to do the same in `glass_general.cpp`, if the wrapped functions fail (when dlsym returns null), we still need to fall back to the old implementation, don't we? Therefore, I've changed the signature to return a `gboolean` (and removed the `GDK_GRAB_FAILED` enum value that was added in 3.16, as I just noticed). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1305#discussion_r1427224949 From jpereda at openjdk.org Thu Dec 14 20:19:12 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 14 Dec 2023 20:19:12 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v2] In-Reply-To: References: Message-ID: > This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: remove compile-time if checks ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1305/files - new: https://git.openjdk.org/jfx/pull/1305/files/f498b835..99230ca6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1305&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1305&range=00-01 Stats: 32 lines in 3 files changed: 5 ins; 8 del; 19 mod Patch: https://git.openjdk.org/jfx/pull/1305.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1305/head:pull/1305 PR: https://git.openjdk.org/jfx/pull/1305 From martin at martinfox.com Thu Dec 14 21:26:13 2023 From: martin at martinfox.com (Martin Fox) Date: Thu, 14 Dec 2023 13:26:13 -0800 Subject: ToggleButton behavior In-Reply-To: References: <487069A6-3B53-4EF7-A21E-D1A86474A1ED@martinfox.com> Message-ID: Hi Andy, The Mozilla doc you pointed to basically re-iterates the W3C guidelines. When a ToggleButton is in a group it should behave like other grouped controls where Tab gets you into and out of the group and the arrow keys navigate within the group. I would still argue that an ungrouped ToggleButton should traverse like any other button. I?m not familiar enough with JavaFX?s focus traversal implementation to have an opinion. Based on past experience I wouldn?t wade into those waters until I had a plan in place for how to validate the results. In my previous job we did a big accessibility push and ended up assigning one engineer whose primary job was liaising with accessibility tool vendors to make sure we got it right. She was worth her weight in gold. (Whatever happened to the issue where multiple nodes in a scene can set their focused property? As I recall someone on the controls side needed to dig in and figure out what was going on there.) Martin > On Dec 7, 2023, at 12:40?PM, Andy Goryachev wrote: > > Dear Martin: > > It's hard to say. How does it work in Swing? > > There is also https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role > > I always felt that the focus management in JavaFX is underdeveloped: multiple focused nodes, nodes getting simultaneous input, lack of coherent geometry-based focus traversal policy, and a lack of public APIs for a custom focus traversal policy. > > Are there any ideas? > > -andy > > > From: openjfx-dev on behalf of Martin Fox > Date: Saturday, December 2, 2023 at 17:58 > To: John Hendrikx > Cc: openjfx-dev > Subject: Re: ToggleButton behavior > > I took a look at the W3C accessibility guidelines for radio button groups since that?s the closest thing I could find to a group of ToggleButtons. The W3C suggests that Tab/Shift+Tab takes you in and out of the group and the arrow keys navigate within the group with wrap-around. Based on that (3) is correct. > > That?s where the W3C guidance ends; a single radio button doesn?t make much sense so it?s not even mentioned. I would expect a single ungrouped ToggleButton to navigate like a checkbox so (1) seems wrong. A group with just one ToggleButton is an odd thing so (2) could go either way. > > Martin > > > On Dec 1, 2023, at 11:21?PM, John Hendrikx wrote: > > In my exploration of a potential Behavior API, I discovered this oddity in how ToggleButtons work. > > 1. If you have a single ToggleButton that is not part of a ToggleGroup, you can't navigate away from it with the arrow keys, only by using Tab or Shift-Tab. > > 2. If you have that same single ToggleButton, but it does have a group (a group of one) then you CAN navigate away from it with the arrow keys. > > 3. When you have two ToggleButtons, both part of the same group, then you can only navigate away from the group with Tab or Shift-Tab again, as the arrow keys will loop back to the first/last button when the end of the group is reached. > > I get the impression at least one of these is incorrect. > > I mean, either ToggleButtons should always loop, even if it is a group of one, meaning (2) would be incorrect... > > Or... ToggleButtons should never loop, in which case (1) and (3) are incorrect... > > Or... Single ToggleButtons (grouped or not) behave differently and don't do looping, in which case (1) is incorrect > > Thoughts? > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Thu Dec 14 22:18:23 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 14 Dec 2023 22:18:23 +0000 Subject: [External] : Re: ToggleButton behavior In-Reply-To: References: <487069A6-3B53-4EF7-A21E-D1A86474A1ED@martinfox.com> Message-ID: Oh yes, this is another of those boxes that belong to Pandora: https://bugs.openjdk.org/issues/?jql=text%20~%20%22focus%20traversal%22%20AND%20project%20%3D%20JDK%20AND%20component%20%3D%20javafx%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20updated%20%20DESC and https://bugs.openjdk.org/browse/JDK-8292933 It?s one of those areas where we could benefit from a redesign or a proper FocusManager. Right now they all sit along with the rest of ~3.5K open tickets, unfortunately. I don?t know what to say. Getting even a small improvement is extremely difficult ? judging by one recent issue - two months of discussion result in a lot of good ideas and zero improvement (at least so far). If a large Oracle customer escalates and requests a fix, that might help. -andy From: Martin Fox Date: Thursday, December 14, 2023 at 13:26 To: Andy Goryachev Cc: John Hendrikx , openjfx-dev Subject: [External] : Re: ToggleButton behavior Hi Andy, The Mozilla doc you pointed to basically re-iterates the W3C guidelines. When a ToggleButton is in a group it should behave like other grouped controls where Tab gets you into and out of the group and the arrow keys navigate within the group. I would still argue that an ungrouped ToggleButton should traverse like any other button. I?m not familiar enough with JavaFX?s focus traversal implementation to have an opinion. Based on past experience I wouldn?t wade into those waters until I had a plan in place for how to validate the results. In my previous job we did a big accessibility push and ended up assigning one engineer whose primary job was liaising with accessibility tool vendors to make sure we got it right. She was worth her weight in gold. (Whatever happened to the issue where multiple nodes in a scene can set their focused property? As I recall someone on the controls side needed to dig in and figure out what was going on there.) Martin On Dec 7, 2023, at 12:40?PM, Andy Goryachev wrote: Dear Martin: It's hard to say. How does it work in Swing? There is also https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role I always felt that the focus management in JavaFX is underdeveloped: multiple focused nodes, nodes getting simultaneous input, lack of coherent geometry-based focus traversal policy, and a lack of public APIs for a custom focus traversal policy. Are there any ideas? -andy From: openjfx-dev on behalf of Martin Fox Date: Saturday, December 2, 2023 at 17:58 To: John Hendrikx Cc: openjfx-dev Subject: Re: ToggleButton behavior I took a look at the W3C accessibility guidelines for radio button groups since that?s the closest thing I could find to a group of ToggleButtons. The W3C suggests that Tab/Shift+Tab takes you in and out of the group and the arrow keys navigate within the group with wrap-around. Based on that (3) is correct. That?s where the W3C guidance ends; a single radio button doesn?t make much sense so it?s not even mentioned. I would expect a single ungrouped ToggleButton to navigate like a checkbox so (1) seems wrong. A group with just one ToggleButton is an odd thing so (2) could go either way. Martin On Dec 1, 2023, at 11:21?PM, John Hendrikx wrote: In my exploration of a potential Behavior API, I discovered this oddity in how ToggleButtons work. 1. If you have a single ToggleButton that is not part of a ToggleGroup, you can't navigate away from it with the arrow keys, only by using Tab or Shift-Tab. 2. If you have that same single ToggleButton, but it does have a group (a group of one) then you CAN navigate away from it with the arrow keys. 3. When you have two ToggleButtons, both part of the same group, then you can only navigate away from the group with Tab or Shift-Tab again, as the arrow keys will loop back to the first/last button when the end of the group is reached. I get the impression at least one of these is incorrect. I mean, either ToggleButtons should always loop, even if it is a group of one, meaning (2) would be incorrect... Or... ToggleButtons should never loop, in which case (1) and (3) are incorrect... Or... Single ToggleButtons (grouped or not) behave differently and don't do looping, in which case (1) is incorrect Thoughts? --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at status6.com Thu Dec 14 23:02:43 2023 From: john at status6.com (John Neffenger) Date: Thu, 14 Dec 2023 15:02:43 -0800 Subject: The crisp fonts saga In-Reply-To: References: <6fe35492269e4e682d6ee6218fa0271a0fd61217.camel@io7m.com> <62ab26d6-33ef-4b0b-b016-4140901939a5@status6.com> Message-ID: <783029e1-ecbf-43dd-b2f1-66a82afaafb0@status6.com> On 12/14/23 4:39 AM, Mark Raynsford wrote: > The key point is "keep text aligned to the pixel grid". The thing is: > This isn't affected by hinting or the lack of it whatsoever, at least > with the way text is implemented in Prism and Freetype, as far as I can > tell. It seems to have influenced the original choice for JavaFX. Felipe Heidrich addresses the font scaling issue at 30:54 in his presentation: Hinting (30m 54s into the video) https://www.youtube.com/watch?v=LCrCni6EVek&t=1854s When using hinting, he says ... ---------------------------------------- You're going to compromise the intent, and again, you're going to compromise the linearity. So again, if you start scaling, things are going to start jumping. They're going to start jumping because they've got to fix the pixel grid here and there, or just like, the stems or the crossbars in the glyphs are going to ... it will go like, point 12, point 13, 14, and things look to be going well, then go 14, 15, kind of gives a jump and everything kind of doubles. It's because of, that's, you're on the next table in your font and that's what the hinting told you to do. And again, so you don't have a nice linear, uh, projection of your font. So all we had here are just workarounds. [Quoting Beat Stamm] "The keywords here are workarounds and tolerable. Workarounds aren't real solutions, and they may not be equally tolerable to everybody." ---------------------------------------- Then he refers to "The Raster Tragedy at Low-Resolution," by Beat Stamm, which is now "The Raster Tragedy at Low-Resolution Revisited." Chapter 6 talks about hinting: 6 Discussions http://rastertragedy.com/RTRCh6.htm John From pedro.duquevieira at gmail.com Thu Dec 14 23:38:20 2023 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 14 Dec 2023 23:38:20 +0000 Subject: The crisp fonts saga Message-ID: No you're not alone on this... I've been complaining of poor text rendering quality on JavaFX for years now. Though in my case, I was complaining about javafx font rendering on Windows. Some of the times I use to call this, that seems to improve font rendering somewhat on some systems: System.setProperty("prism.lcdtext", "false"); Javafx font rendering on Mac OS is better than on Windows. When I worked for a very well known company here, we used to do all the product screenshots on Mac because it would look noticeably better than on Windows (I use Windows) because of the poor font rendering quality on that OS. Given the majority of desktop users use Windows this is even more of a problem. My 2 cents. Cheers, -- Pedro Duque Vieira - https://www.pixelduke.com Sem v?rus.www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at status6.com Fri Dec 15 05:29:36 2023 From: john at status6.com (John Neffenger) Date: Thu, 14 Dec 2023 21:29:36 -0800 Subject: The crisp fonts saga In-Reply-To: <62ab26d6-33ef-4b0b-b016-4140901939a5@status6.com> References: <6fe35492269e4e682d6ee6218fa0271a0fd61217.camel@io7m.com> <62ab26d6-33ef-4b0b-b016-4140901939a5@status6.com> Message-ID: On 12/13/23 10:15 PM, John Neffenger wrote: > I find it helps to get the bigger picture. Below are the various camps > as I've come to understand them over the years. An update to my previous categorization ... In 2018, Java Swing moved from the full-hinting group to the slight-hinting group, on Linux at least, when FreeType 2.8 was included in Linux distributions. So a better grouping of rendering policies is: Subpixel rendering with normal hinting - Microsoft Windows - Java Swing on Linux (before FreeType 2.8) Subpixel rendering with "slight" hinting - Ubuntu - Java Swing on Linux (after FreeType 2.8) Subpixel rendering with hinting disabled - JavaFX on Linux Gray-level rendering with hinting disabled - Apple macOS I always wondered why text rendering in Swing apps on Linux got so much better around 2018. Turns out FreeType made the switch under the covers with the following change [1]: - FT_LOAD_TARGET_LCD is now a variant of FT_LOAD_TARGET_LIGHT; this should provide better rendering results. Better indeed! A five-year mystery (to me, at least) solved. :-) John [1]: https://sourceforge.net/projects/freetype/files/freetype2/2.8/ From org.openjdk at io7m.com Fri Dec 15 11:39:48 2023 From: org.openjdk at io7m.com (Mark Raynsford) Date: Fri, 15 Dec 2023 11:39:48 +0000 Subject: The crisp fonts saga In-Reply-To: <783029e1-ecbf-43dd-b2f1-66a82afaafb0@status6.com> References: <6fe35492269e4e682d6ee6218fa0271a0fd61217.camel@io7m.com> <62ab26d6-33ef-4b0b-b016-4140901939a5@status6.com> <783029e1-ecbf-43dd-b2f1-66a82afaafb0@status6.com> Message-ID: <119a5d12f9ed439edda17634727fcf55c1b05932.camel@io7m.com> On Thu, 2023-12-14 at 15:02 -0800, John Neffenger wrote: > On 12/14/23 4:39 AM, Mark Raynsford wrote: > > The key point is "keep text aligned to the pixel grid". The thing > > is: > > This isn't affected by hinting or the lack of it whatsoever, at > > least > > with the way text is implemented in Prism and Freetype, as far as I > > can > > tell. > > It seems to have influenced the original choice for JavaFX. Felipe > Heidrich addresses the font scaling issue at 30:54 in his > presentation: > > Hinting (30m 54s into the video) > https://www.youtube.com/watch?v=LCrCni6EVek&t=1854s > > When using hinting, he says ... > > ---------------------------------------- > You're going to compromise the intent, and again, you're going to > compromise the linearity. So again, if you start scaling, things are > going to start jumping. > > They're going to start jumping because they've got to fix the pixel > grid > here and there, or just like, the stems or the crossbars in the > glyphs > are going to ... it will go like, point 12, point 13, 14, and things > look to be going well, then go 14, 15, kind of gives a jump and > everything kind of doubles. So what he's describing is scaling in terms of changing the underlying font size and regenerating glyphs at each animation step. As in, if you implement zooming text by displaying fonts at size 12.12pt, 12.13pt, 12.14pt, etc. Is this really such a serious problem and urgent use-case that we have to live with awful text rendering to support it? The only applications I can think of that do text zooming like this are web browsers and, even there, there's no expectation of smoothly animating fonts between different sizes (and the layout is going to jump around all over the place anyway, due to other objects on web pages changing sizes). This seems like an extremely bad trade-off. These days, we have GPUs. Render text at a few fixed sizes and linearly interpolate between the rendered images whilst scaling up nodes. I highly doubt users would notice or care about the difference. -- Mark Raynsford | https://www.io7m.com From org.openjdk at io7m.com Fri Dec 15 11:44:46 2023 From: org.openjdk at io7m.com (Mark Raynsford) Date: Fri, 15 Dec 2023 11:44:46 +0000 Subject: The crisp fonts saga In-Reply-To: References: Message-ID: <278c73515293b33d73bd2e49701b95127722e5e3.camel@io7m.com> On Thu, 2023-12-14 at 23:38 +0000, Pedro Duque Vieira wrote: > > System.setProperty("prism.lcdtext", "false"); > > > Javafx font rendering on Mac OS is better than on Windows. Yeah, I've had a go with this as well. On Windows 10, at least, the choice is between blurry text, or blurry text with awful colour fringing. Not great! -- Mark Raynsford | https://www.io7m.com From john.hendrikx at gmail.com Fri Dec 15 14:28:04 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 15 Dec 2023 15:28:04 +0100 Subject: The crisp fonts saga In-Reply-To: <278c73515293b33d73bd2e49701b95127722e5e3.camel@io7m.com> References: <278c73515293b33d73bd2e49701b95127722e5e3.camel@io7m.com> Message-ID: <2798dc71-c53c-4b83-d7a6-cb3bbd51de4e@gmail.com> I've done this for FX, but also for Windows globally.? Even on 4K screens (with the correct LCD pixel order) I notice color fringing, so I've forced Windows to use grayscale anti aliasing everywhere.? I just can't stand glyphs looking like they come from a circus poster. --John On 15/12/2023 12:44, Mark Raynsford wrote: > On Thu, 2023-12-14 at 23:38 +0000, Pedro Duque Vieira wrote: >> System.setProperty("prism.lcdtext", "false"); >> >> >> Javafx font rendering on Mac OS is better than on Windows. > Yeah, I've had a go with this as well. On Windows 10, at least, > the choice is between blurry text, or blurry text with awful colour > fringing. > > Not great! > From kcr at openjdk.org Fri Dec 15 14:29:58 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Dec 2023 14:29:58 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v2] In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 20:19:12 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > remove compile-time if checks This now looks like what I would expect. I'll test it, mainly to look for regressions, since I don't have a touch screen to test the actual fix. @tsayao Can you be the second reviewer? ------------- PR Review: https://git.openjdk.org/jfx/pull/1305#pullrequestreview-1784185499 From kcr at openjdk.org Fri Dec 15 14:30:00 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Dec 2023 14:30:00 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v2] In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 20:13:36 GMT, Jose Pereda wrote: >> modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp line 599: >> >>> 597: return TRUE; >>> 598: } >>> 599: #if GTK_CHECK_VERSION(3, 20, 0) >> >> I wouldn't have expected any compile-time `#if` checks as part of this PR. > > Okay, that makes sense. > > I've removed the compile-time `#if-#else` from `wrapped.c`. > > However, to do the same in `glass_general.cpp`, if the wrapped functions fail (when dlsym returns null), we still need to fall back to the old implementation, don't we? > > Therefore, I've changed the signature to return a `gboolean` (and removed the `GDK_GRAB_FAILED` enum value that was added in 3.16, as I just noticed). This looks good. I'll review more closely and also test it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1305#discussion_r1428032274 From kcr at openjdk.org Fri Dec 15 18:29:51 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Dec 2023 18:29:51 GMT Subject: RFR: 8301219: JavaFX crash when closing with the escape key In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 00:58:56 GMT, Martin Fox wrote: > While processing a key down event the Glass GTK code sends out PRESSED and TYPED KeyEvents back to back. If the stage is closed during the PRESSED event the code will end up referencing freed memory while sending out the TYPED event. This can lead to intermittent crashes. > > In GlassApplication.cpp the EventCounterHelper object ensures the WindowContext isn't deleted while processing an event. Currently the helper object is being created *after* IME handling instead of before. If the IME is enabled it's possible for the WindowContext to be deleted in the middle of executing a number of keyboard-related events. > > The fix is simple; instantiate the EventCounterHelper object earlier. There isn't always a WindowContext so I tweaked the EventCounterHelper to do nothing if the context is null. > > To make the crash more reproducible I altered the WindowContext such that when it's deleted the freed memory is filled with 0xCC. This made the crash more reproducible and allowed me to test the fix. I did the same with GlassView since that's the only other Glass GTK class that's instantiated with `new` and discarded with `delete`. The fix looks good. I tested it by reverting your fix and leaving in the debug memory fill on delete. The system test added by this PR crashes without the fix and passes with the fix. So do the tests associated with the fixed bugs. I also ran a headful test run on our lab systems. All good. As for the debug fill-on-delete code, it seems useful to have it available, but not enabled in production. I recommend to ifdef it out on a flag, either DEBUG or some unique flag defined in `DeletedMemDebug.h`, but off by default. ------------- PR Review: https://git.openjdk.org/jfx/pull/1307#pullrequestreview-1784710942 From martin at martinfox.com Fri Dec 15 19:36:56 2023 From: martin at martinfox.com (Martin Fox) Date: Fri, 15 Dec 2023 11:36:56 -0800 Subject: Issues running SwingNodeJDialogTest on Linux Message-ID: <5BB0A51E-012F-46A6-8B95-D8CA1BCCC070@martinfox.com> I?m having an issue with one of the robot tests on my Linux machine. Before I dig any further I could use some guidance on where to look. I?m running Ubuntu 22.04 on ARM64 (in a Parallels VM). The command line I?m using is: bash ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests SwingNodeJDialogTest The truly puzzling behavior is that the test never stops executing. I?ve got it running right now and it says it?s been executing for over 40 minutes. Shouldn?t the testing framework time this out? Under the hood I believe that the Glass code in launcher.c is detecting that a GTK 2 library is already loaded so it bails. From what I can tell both JavaFX and Swing should default to GTK 3 so that?s also puzzling. Any help would be appreciated. Thanks, Martin From mfox at openjdk.org Fri Dec 15 20:57:01 2023 From: mfox at openjdk.org (Martin Fox) Date: Fri, 15 Dec 2023 20:57:01 GMT Subject: RFR: 8301219: JavaFX crash when closing with the escape key [v2] In-Reply-To: References: Message-ID: > While processing a key down event the Glass GTK code sends out PRESSED and TYPED KeyEvents back to back. If the stage is closed during the PRESSED event the code will end up referencing freed memory while sending out the TYPED event. This can lead to intermittent crashes. > > In GlassApplication.cpp the EventCounterHelper object ensures the WindowContext isn't deleted while processing an event. Currently the helper object is being created *after* IME handling instead of before. If the IME is enabled it's possible for the WindowContext to be deleted in the middle of executing a number of keyboard-related events. > > The fix is simple; instantiate the EventCounterHelper object earlier. There isn't always a WindowContext so I tweaked the EventCounterHelper to do nothing if the context is null. > > To make the crash more reproducible I altered the WindowContext such that when it's deleted the freed memory is filled with 0xCC. This made the crash more reproducible and allowed me to test the fix. I did the same with GlassView since that's the only other Glass GTK class that's instantiated with `new` and discarded with `delete`. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Debugging code turned off by default. Empty line removed. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1307/files - new: https://git.openjdk.org/jfx/pull/1307/files/ccb60e84..6a4a4e63 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1307&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1307&range=00-01 Stats: 5 lines in 2 files changed: 4 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1307.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1307/head:pull/1307 PR: https://git.openjdk.org/jfx/pull/1307 From kevin.rushforth at oracle.com Fri Dec 15 21:35:39 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 15 Dec 2023 13:35:39 -0800 Subject: Issues running SwingNodeJDialogTest on Linux In-Reply-To: <5BB0A51E-012F-46A6-8B95-D8CA1BCCC070@martinfox.com> References: <5BB0A51E-012F-46A6-8B95-D8CA1BCCC070@martinfox.com> Message-ID: Hmm. That's odd. you could pass "-Djdk.gtk.verbose=true" and see what's happening on the GTK loading side. Both AWT and JavaFX will print some info if that system property it set. To find out where the test process is hung you can use "jstack PID". If the test itself is hung, then that test would be a good candidate for adding a timeout parameter to the "@Test" tag. -- Kevin On 12/15/2023 11:36 AM, Martin Fox wrote: > I?m having an issue with one of the robot tests on my Linux machine. Before I dig any further I could use some guidance on where to look. > > I?m running Ubuntu 22.04 on ARM64 (in a Parallels VM). The command line I?m using is: > > bash ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests SwingNodeJDialogTest > > The truly puzzling behavior is that the test never stops executing. I?ve got it running right now and it says it?s been executing for over 40 minutes. Shouldn?t the testing framework time this out? > > Under the hood I believe that the Glass code in launcher.c is detecting that a GTK 2 library is already loaded so it bails. From what I can tell both JavaFX and Swing should default to GTK 3 so that?s also puzzling. > > Any help would be appreciated. > > Thanks, > Martin From philip.race at oracle.com Fri Dec 15 21:40:22 2023 From: philip.race at oracle.com (Philip Race) Date: Fri, 15 Dec 2023 13:40:22 -0800 Subject: The crisp fonts saga In-Reply-To: <2798dc71-c53c-4b83-d7a6-cb3bbd51de4e@gmail.com> References: <278c73515293b33d73bd2e49701b95127722e5e3.camel@io7m.com> <2798dc71-c53c-4b83-d7a6-cb3bbd51de4e@gmail.com> Message-ID: I already gave a brief explanation of why FX text rendering is what it is. I will expand on it a bit but a number of the salient points have already been made by others. It is unlikely we will make anything other than carefully considered tweaks, so this is by way of explanation. I'm not going to try to reply directly every single point made in this already very long thread, I'm just going to tell it as I see it. My experience is that above anything else in UIs, text rendering is a topic that generates a lot of heat / discussion / etc and some times opinion are colored by experience. There's the old quote "You can please some of the people some of the time, all of the people some of the time, some of the people all of the time, but you can never please all of the people all of the time." As applied to font rendering it is more like "You can please some of the people some of the time" and the quote stops right there ! At best ! Some people absolutely insist that being true to the design is what is most important A high contrast is the most important to someone else. No jaggies is important to another person. Hinting is essential to some people in some cases. To other people it is anathema. etc, etc. Every one of these decisions and the consequences is sure to fall foul of someone's views, If you want to reply to a specific point / decision / choice disagreeing with it, I'll not be surprised because opinions differ. Even if you can actually get several people to agree in principle on what they want, someone else will disagree, BUT you'll also run into the feasibility of it and consequences. Overall, FX hasn't tried to look like the platform and to some extent that carries over into the text. Meaning whereas Swing would provide a platform L&F and go to great lengths to use the SAME font in the SAME way, FX has no contract to do that. And on top of that it isn't just arbitrary application of the tastes of one FX UX architect back in the day. There are technical issues behind it. Having said that FX is not trying to emulate the platform, it is actually using platform APIs to do all the rendering. But what is "the" platform API ? On Windows, many people prefer GDI rendering, whereas FX uses the more modern DirectWrite API. And some people are very unhappy with DW in general "https://superuser.com/questions/1484267/permanently-delete-directwrite-from-microsoft-windows" You can find plenty more examples like this. And of course Windows itself at the end user configuration level, as well as for applications directly using APIs like DW and freetype often provide some set of knobs that affect some aspect of the rendering. So there is no single true "the platform rendering". A bit more history. The first version of FX didn't have its own graphics pipeline, it was a wrapper around Java 2D & AWT. T2K was used by Sun / Oracle JDK since JDK 1.2. It was written by one of the original TrueType developers at Apple The hinting support in it came directly from Apple. So it was in fact quite good at what it did. But it was a snapshot, so over time it became old and we had to maintain it and update it ourselves, fixing bugs, adding new features. So JavaFX used T2K implicitly. Actually one of the 'knocks' on T2K for FX was that there was some truly appalling rendering of a family of fonts called "Amble" which Sun had commercially licensed to be included with FX applications and provide FX apps with a consistent look across platforms. It turned out that the problem was because those fonts were evaluated on the Apple platform looking at how macOS rendered them. macOS even then ignored hints. And it turned out that these fonts were hinted, and specified in the 'gasp' table to apply those hints but the hints were terrible. The solution was to turn off hinting when using those fonts and then it was fine, but by then there was already a perception of T2K as "poor", when really it was the fonts and the mistake was to have licensed them. Other commercial font rasteriser products were considered to be included instead in FX's own native Prism pipeline. But using T2K was also considered for FX because licensing an additional font technology is extremely expensive. But the direction of going open source ultimately forced the decision to use platform APIs, but that doesn't make it a bad decision, although it meant you now could never have a consistent cross-platform look that you controlled and had to manage at least 3 implementations. Open-sourcing also meant the Amble fonts were dropped because they could not be open-sourced. [BTW a similar thing happened when JDK was open sourced : T2K was dropped and so were the Lucida fonts] But what comes out of all of this history is that un-hinted, macOS-like rendering is what was wanted for FX for aesthetic? (yes, such a thing is subjective, I'm just telling the story) reasons Even when hi-dpi displays were rare. But there were technical reasons too. Java 2D/Swing uses hinting. As well as using GDI rendering not DW. But there's a price to pay. Swing UIs do not scale linearly. Text measurement needs to be given the true final scale used during rendering to the device to be able to layout a UI. This is painful to do and get right. Also even if you do that it means that if you have something like a text area and you go to print the formatted content, you do NOT get WYSIWYG. It needs to be re-flowed for printer resolution. And hi-dpi displays, or even moderately scales like windows 1.25 scale affect the layout of apps. And app developers all too often get this wrong. And if you drag a window from one screen to another with different scales, Swing needs to do re-layout due to this. This is a part of the reason retro-fitting Swing to support hidpi on windows is still suffering from a bug tail. This is all down to using hinting. And "bitmaps" in a font are extremely rare. I think one Windows font that isn't a CJK font (Garamond) has them, and ultimately they are just a pre-composed hinted image, available only at select sizes. So being able to point to one font and the results of using bitmaps there isn't anything approaching a useful solution. And animations using text - not common in Swing, but central to FX - are very jerky if you use hinting. Tricks like taking an image for the whole string and transforming that work OK if the animation is going at a speed no one can see. But if you stop it at some point, or slow it, it is obvious, and if you at the stopped point re-draw as hinted text, there can be an obvious brief discontinuity. And then on top of that hinting is not even designed to be used in such rotated cases. It is adjusting the outline on the assumption that it causes a pixel to be touched on the unrotated grid. If it is rotated - or sheared, the hints are not easily applied. And to make matters worse, hinting is about aligning to the pixel grid and there are even pre-composed integer advances to be used for the hinted glyphs. These can map very poorly to a non-integral position when rotating, so independently of animation the advances between glyphs can look extremely uneven and also cause a non-straight baseline. And as the Amble case points out, you are dependent on the quality of the hinting which is very expensive. Poor hinting is worse than none. Microsoft ship well hinted fonts but they have deep pockets. On Linux, at least historically, hinting was patchy at best in the various free fonts. LCD text also doesn't work well with rotations because the 3X resolution you get is only in one orientation. And you absolutely CANNOT use the image scaling trick in this case, else the people already complaining about color fringing will go bananas. So far as I can tell Apple got rid of LCD in part because it made no sense on iOS where people rotate devices and they have hidpi screens, but I agree with anyone who thinks it was a bit premature to remove it from the macOS desktop where they don't always control the display device, but that's Apple. Perhaps their solution is "please buy one of our expensive retina displays". So the "Text" node defaults to greyscale, whereas UI controls, which are much less likely to be transformed in such a way, default to LCD (or at least should, I wasn't sure if some of those Linux images Thiago posted were grey or LCD). LCD whilst not popular in some circles, is what Windows UIs use and offers better contrast than the greyscale. Not everyone notices or is bothered by fringing. This is one of those compromises. So ultimately getting rid of all such workarounds, meaning mainly hinting and LCD sub-pixel text which address limitations of the raster grid brings with it benefits such as consistent layout, simpler APIs, more true rendering of the font. The major downside is lower-contrast text that doesn't look so good on lower-dpi devices because fewer pixels are solid black (or whatever the text color is). Possibly (only possibly) FT_LOAD_TARGET_LIGHT is something that could be used at least in conjunction with LCD text on Linux if it really has no impact on string length. Or anything else that matters. Quite possibly it wasn't even doing the same thing back when the current freetype settings were coded up. And we produce a single binary that has to run on Linux versions from ancient to cutting edge. I have no idea if current versions of DW offer something similar. Oh, one other problem is that IIRC, Modena either uses "not quite black" as the text color or it is on top of a "not quite white" background, or something like that. So that doesn't help in getting better contrast or reducing fringing. -phil. From org.openjdk at io7m.com Fri Dec 15 22:21:24 2023 From: org.openjdk at io7m.com (Mark Raynsford) Date: Fri, 15 Dec 2023 22:21:24 +0000 Subject: The crisp fonts saga In-Reply-To: References: <278c73515293b33d73bd2e49701b95127722e5e3.camel@io7m.com> <2798dc71-c53c-4b83-d7a6-cb3bbd51de4e@gmail.com> Message-ID: On Fri, 2023-12-15 at 13:40 -0800, Philip Race wrote: > I already gave a brief explanation of why FX text rendering is what > it is. > I will expand on it a bit but a number of the salient points have > already been made by others. > It is unlikely we will make anything other than carefully considered > tweaks, so this is by way of explanation. I'm actually not even asking to change the defaults. The dictated-from- above defaults are the problem. I am inevitably going to fork JavaFX and maintain a patched version even if the changes won't be accepted upstream. These are the changes I intend to make: 1. Add an -fx-font-bitmaps CSS attribute that, by default, will be set to false. Setting this value to true will cause bitmap information to be loaded if present, and ignored otherwise. 2. Add an -fx-font-hinting CSS attribute that, by default, will be set to false. Setting this value to true will enable hinting using whatever is the default (in other words, not setting FT_LOAD_NO_HINTING). 3. Add an extra value to -fx-font-smoothing: none. Setting this will use FT_LOAD_TARGET_MONO and disable effectively disable antialiasing. This is important for my users for small-text console components. I'm just tired of my applications looking like optical migraines when everyone else on the planet (including the UI library in the JDK itself) manages to look better, regardless of the apparent technical consequences for frankly niche cases. > Some people absolutely insist that being true to the design is what? > is most important > A high contrast is the most important to someone else. > No jaggies is important to another person. > Hinting is essential to some people in some cases. To other people it > is anathema. etc, etc. And by disallowing developers to change the behaviour in any way, you're deciding this for them. You're effectively pleasing the smallest set of people possible. > And then on top of that hinting is not even designed to be used in > such rotated cases. So we must all pay for ugly text because someone somewhere wants to spin text around, and we don't get to opt-out. > And as the Amble case points out, you are dependent on the quality of > the hinting which is very expensive. Poor hinting is worse than none. So JavaFX, which has no idea which fonts I'm bundling, is clearly more qualified than I am to decide whether I want hinting or not. > And animations using text - not common in Swing, but central to FX - > are very jerky if you use hinting. It's almost as if there's some kind of design flaw, and a ton of work to maintain a feature that I've yet to see anyone actually say that they care about. Take a look at any modern 3D rendering engine with UI support, and you won't see these issues, and they not only perform scaling and rotation but frequently perspective projection onto 3D surfaces. > And "bitmaps" in a font are extremely rare. Maybe in the fonts you use. "Extremely rare" is entirely subjective; there's an entire field of programmer fonts that use carefully tuned bitmaps to stay sharp. Guess we're just not allowed to use those either, because JavaFX says so. > LCD text also doesn't work well with rotations because the 3X? > resolution you get is only in one orientation. On that we agree. I have no interest in LCD text on any platform. Guess I'll get working on the fork. -- Mark Raynsford | https://www.io7m.com From michaelstrau2 at gmail.com Fri Dec 15 22:39:44 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 15 Dec 2023 23:39:44 +0100 Subject: The crisp fonts saga In-Reply-To: References: <278c73515293b33d73bd2e49701b95127722e5e3.camel@io7m.com> <2798dc71-c53c-4b83-d7a6-cb3bbd51de4e@gmail.com> Message-ID: Hi Mark, maybe you should start a new thread with your proposed API and a quick summary of the problems that it solves. OpenJFX is a community effort after all, so let?s see whether we can get your proposal accepted. Mark Raynsford schrieb am Fr. 15. Dez. 2023 um 23:21: > On Fri, 2023-12-15 at 13:40 -0800, Philip Race wrote: > > I already gave a brief explanation of why FX text rendering is what > > it is. > > I will expand on it a bit but a number of the salient points have > > already been made by others. > > It is unlikely we will make anything other than carefully considered > > tweaks, so this is by way of explanation. > > I'm actually not even asking to change the defaults. The dictated-from- > above defaults are the problem. I am inevitably going to fork JavaFX > and maintain a patched version even if the changes won't be accepted > upstream. These are the changes I intend to make: > > 1. Add an -fx-font-bitmaps CSS attribute that, by default, will be > set to false. Setting this value to true will cause bitmap > information to be loaded if present, and ignored otherwise. > > 2. Add an -fx-font-hinting CSS attribute that, by default, will be > set to false. Setting this value to true will enable hinting > using whatever is the default (in other words, not setting > FT_LOAD_NO_HINTING). > > 3. Add an extra value to -fx-font-smoothing: none. Setting this > will use FT_LOAD_TARGET_MONO and disable effectively disable > antialiasing. This is important for my users for small-text > console components. > > I'm just tired of my applications looking like optical migraines when > everyone else on the planet (including the UI library in the JDK > itself) manages to look better, regardless of the apparent technical > consequences for frankly niche cases. > > > Some people absolutely insist that being true to the design is what > > is most important > > A high contrast is the most important to someone else. > > No jaggies is important to another person. > > Hinting is essential to some people in some cases. To other people it > > is anathema. etc, etc. > > And by disallowing developers to change the behaviour in any way, > you're deciding this for them. You're effectively pleasing the smallest > set of people possible. > > > And then on top of that hinting is not even designed to be used in > > such rotated cases. > > So we must all pay for ugly text because someone somewhere wants to > spin text around, and we don't get to opt-out. > > > And as the Amble case points out, you are dependent on the quality of > > the hinting which is very expensive. Poor hinting is worse than none. > > So JavaFX, which has no idea which fonts I'm bundling, is clearly more > qualified than I am to decide whether I want hinting or not. > > > And animations using text - not common in Swing, but central to FX - > > are very jerky if you use hinting. > > It's almost as if there's some kind of design flaw, and a ton of work > to maintain a feature that I've yet to see anyone actually say that > they care about. Take a look at any modern 3D rendering engine with UI > support, and you won't see these issues, and they not only perform > scaling and rotation but frequently perspective projection onto 3D > surfaces. > > > And "bitmaps" in a font are extremely rare. > > Maybe in the fonts you use. "Extremely rare" is entirely subjective; > there's an entire field of programmer fonts that use carefully tuned > bitmaps to stay sharp. Guess we're just not allowed to use those > either, because JavaFX says so. > > > LCD text also doesn't work well with rotations because the 3X > > resolution you get is only in one orientation. > > On that we agree. I have no interest in LCD text on any platform. > > Guess I'll get working on the fork. > > -- > Mark Raynsford | https://www.io7m.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at status6.com Sat Dec 16 01:23:15 2023 From: john at status6.com (John Neffenger) Date: Fri, 15 Dec 2023 17:23:15 -0800 Subject: The crisp fonts saga In-Reply-To: References: <278c73515293b33d73bd2e49701b95127722e5e3.camel@io7m.com> <2798dc71-c53c-4b83-d7a6-cb3bbd51de4e@gmail.com> Message-ID: <440bcb7d-6ff6-4822-b639-2bf3d09878bb@status6.com> On 12/15/23 1:40 PM, Philip Race wrote: > I will expand on it a bit but a number of the salient points have > already been made by others. Thank you, Phil, for taking the time to write down the history. I truly appreciate it, and it's very helpful. Those of us outside of Oracle know the "what" about the big design decisions made in JavaFX, but we're often missing all of the "why." Your message helps to close that gap. > Possibly (only possibly) FT_LOAD_TARGET_LIGHT is something that could be > used at least in conjunction > with LCD text on Linux if it really has no impact on string length. Thank you, too, for noticing that! John From john at status6.com Sat Dec 16 01:55:25 2023 From: john at status6.com (John Neffenger) Date: Fri, 15 Dec 2023 17:55:25 -0800 Subject: The crisp fonts saga In-Reply-To: References: <278c73515293b33d73bd2e49701b95127722e5e3.camel@io7m.com> <2798dc71-c53c-4b83-d7a6-cb3bbd51de4e@gmail.com> Message-ID: On 12/15/23 2:21 PM, Mark Raynsford wrote: > 2. Add an -fx-font-hinting CSS attribute that, by default, will be > set to false. Setting this value to true will enable hinting > using whatever is the default (in other words, not setting > FT_LOAD_NO_HINTING). Have you thought of a 'prism.hinting' system property similar to the current 'prism.lcdtext'? Simply being able to toggle off FT_LOAD_NO_HINTING would, I think, result in text rendering on Linux similar to the JDK (vertical-only hinting when using FreeType 2.8 or later). A system property would allow end users to control the hinting, too, with the added benefit of being a very simple code change. John From john.hendrikx at gmail.com Sat Dec 16 04:59:25 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sat, 16 Dec 2023 05:59:25 +0100 Subject: Mocking library Message-ID: <7d0055a4-cb13-a15a-57f0-a68e0ac2d6aa@gmail.com> Hi, Would it be a good idea to include a mocking library like Mockito to FX's test tools? I often find myself wanting to test components in isolation, to avoid having to spin up large parts of FX to even get something as simple as a Control testable.? So far I've avoided the issue as I've been working mostly in javafx.base which can be tested pretty easily.? However, in javafx.graphics I find that testing is a lot more cumbersome, and I think as a result, many things are not tested as well as they should be. A mocking library can help immensily with this burden, allowing you to test components like Skins and Behaviors in isolation by providing a Control mock. In my exploration of a potential Behavior API, I noticed quite a few edge cases that are not tested at all, or would be very hard to test if one has to use real components and get them to be in a very specific state to test the edge case. It's use of course would at the disgression of the test author, and normally such a library gets included the first time someone needs it, but in FX I think this process is a bit more formal (as it is was with the JUnit 5 upgrade, requiring some external approval I think) and so I'd like to get this library in before we need it. --John From john.hendrikx at gmail.com Sat Dec 16 05:53:09 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sat, 16 Dec 2023 06:53:09 +0100 Subject: New API: Animation/Timeline improvement Message-ID: <1991b717-755e-d44f-9537-99b583b0904a@gmail.com> Hi list, I've noticed that Animations and Timelines are often a source of leaks, and their clean-up is often either non-existent or incorrect.? The reason they cause leaks easily is because a running animation or timeline is globally referred from a singleton PrimaryTimer.? The animation or timeline then refers to properties or event handlers which refer to controls (which refer to parents and the entire scene). For example: - ScrollBarBehavior uses a Timeline, but neglects to clean it up.? If it was running at the time a Scene is detached from a Window, and that Scene is left to go out of scope, it won't because Timeline refers it; this can happen if the behavior never receives a key released event. - ScrollBarBehavior has no dispose method overridden, so swapping Skins while the animation is running will leave a Timeline active (it uses Animation.INDEFINITE) - SpinnerBehavior has flawed clean up; it attaches a Scene listener and disables its timeline when the scene changed, but the scene doesn't have to change for it to go out of scope as a whole... Result is that if you have a spinner timeline running, and you close the entire window (no Scene change happens), the entire Scene will still be referred.? It also uses an indefinite cycle count.? It also lacks a dispose method, so swapping Skins at a bad moment can also leave a reference. I think these mistakes are common, and far too easy to make.? The most common use cases for animations revolve around modifying properties on visible controls, and although animations can be used for purposes other than animating UI controls, this is extremely rare.? So it is safe to say that in 99% of cases you want the animation to stop once a some Node is no longer showing. For both the mentioned buggy behaviors above, this would be perfect.? A spinner stops spinning when no longer showing, and a scroll bar stops scrolling when no longer showing.? It is also likely to apply for many other uses of timelines and animations. I therefore want to propose a new API, either on Node or Animation (or both): ??? /** ???? * Creates a new timeline which is stopped automatically when this Node ???? * is no longer showing. Stopping timelines is essential as they may refer ???? * nodes even after they are no longer used anywhere, preventing them from ???? * being garbage collected. ???? */ ??? Node.createTimeline();? // and variants with the various Timeline constructors And/or: ??? /** ???? * Links this Animation to the given Node, and stops the animation ???? * automatically when the Node is no longer showing. Stopping animations ???? * is essential as they may refer nodes even after they are no longer used ???? * anywhere, preventing them from being garbage collected. ???? */ ??? void stopWhenHidden(Node node); The above API for Animation could also be provided through another constructor, which takes a Node which will it be linked to. Alternatives: - Be a lot more diligent about cleaning up animations and timelines (essentially maintain the status quo which has led to above bugs) - Use this lengthy code fragment below: ??? Timeline timeline = new Timeline(); ??? someNode.sceneProperty() ??????? .when(timeline.statusProperty().map(status -> status != Status.STOPPED)) ??????? .flatMap(Scene::windowProperty) ??????? .flatMap(Window::showingProperty) ??????? .orElse(false) ??????? .subscribe(showing -> { ??????????? if (!showing) timeline.stop(); ??????? }); The `when` line ensures that the opposite problem (Nodes forever referencing Timelines) doesn't occur if you are creating a new Timeline for each use (not recommended, but nonetheless a common occurrence). --John From org.openjdk at io7m.com Sat Dec 16 11:30:58 2023 From: org.openjdk at io7m.com (Mark Raynsford) Date: Sat, 16 Dec 2023 11:30:58 +0000 Subject: The crisp fonts saga In-Reply-To: References: <278c73515293b33d73bd2e49701b95127722e5e3.camel@io7m.com> <2798dc71-c53c-4b83-d7a6-cb3bbd51de4e@gmail.com> Message-ID: On Fri, 2023-12-15 at 17:55 -0800, John Neffenger wrote: > On 12/15/23 2:21 PM, Mark Raynsford wrote: > > ?? 2. Add an -fx-font-hinting CSS attribute that, by default, will > > be > > ????? set to false. Setting this value to true will enable hinting > > ????? using whatever is the default (in other words, not setting > > ????? FT_LOAD_NO_HINTING). > > Have you thought of a 'prism.hinting' system property similar to the > current 'prism.lcdtext'? > > Simply being able to toggle off FT_LOAD_NO_HINTING would, I think, > result in text rendering on Linux similar to the JDK (vertical-only > hinting when using FreeType 2.8 or later). > > A system property would allow end users to control the hinting, too, > with the added benefit of being a very simple code change. I have, yes. I actually considered properties for each of these, but I thought it more important to be able to specify them on a node-by-node basis. Of course, I could always do both, as with the way font smoothing is right now (prism.lcdtext and -fx-font-smoothing-type: gray). :) -- Mark Raynsford | https://www.io7m.com From eran at leshem.life Sat Dec 16 14:07:24 2023 From: eran at leshem.life (Eran Leshem) Date: Sat, 16 Dec 2023 16:07:24 +0200 Subject: Converting a Color object to its string representation In-Reply-To: <02d77b6d-8646-446f-9cee-126fd3434a8c@oracle.com> References: <079901da2c77$85199e70$8f4cdb50$@leshem.life> <1BB9FE54-1C72-4B7A-9F45-E55C02DDAA54@gmail.com> <006501da2d57$fd6350c0$f829f240$@leshem.life> <02d77b6d-8646-446f-9cee-126fd3434a8c@oracle.com> Message-ID: <036901da3029$32e98c90$98bca5b0$@leshem.life> Thanks. The #rrggbbaa format isn?t documented on https://openjfx.io/javadoc/21/javafx.graphics/javafx/scene/doc-files/cssref.html#typecolor for some reason, so I missed it. Can I contribute a fix to the doc? What?s the process for approving option 1? Eran From: openjfx-dev [mailto:openjfx-dev-retn at openjdk.org] On Behalf Of Kevin Rushforth Sent: Wednesday, December 13, 2023 2:46 PM To: openjfx-dev at openjdk.org Subject: Re: Converting a Color object to its string representation Or the third option: 3. Do nothing I would go for option 1 or 3. I do not recommend option 2. I see some value in a minimal API (option 1), returning a fixed format, perhaps: if alpha == 1 { "#rrggbb" } else { "#rrggbbaa" } -- Kevin On 12/12/2023 4:04 PM, Eran Leshem wrote: I can see two options: 1. Minimal, just in order to satisfy the style APIs need ? supporting a single format. I would go with non-% rgba, since it covers all dimensions in the most straightforward way. 2. Complete ? supporting all formats accepted by Color.web(), either via multiple methods or via an enum parameter Eran From: openjfx-dev [mailto:openjfx-dev-retn at openjdk.org] On Behalf Of Andy Goryachev Sent: Tuesday, December 12, 2023 6:08 PM To: Scott Palmer; openjfx-dev at openjdk.org Subject: Re: Converting a Color object to its string representation I also think that the platform will benefit from adding this symmetrical API. It is less clear how that new API should deal with all the multiple variants of the web format (#rgb, #rrggbb, rgb, rgba, 0x*, ...). -andy From: openjfx-dev on behalf of Scott Palmer Date: Monday, December 11, 2023 at 17:12 To: openjfx-dev at openjdk.org Subject: Re: Converting a Color object to its string representation I agree. I was going to write pretty much this exact email, but you beat me to it. I was implementing some user-configurable colour customizations in an application and needed to do it with style sheets, along with something that reads colours along the lines of what the new platform preferences API does. I make a base64 data URL from a dynamically generated style sheet to avoid writing temp CSS files to style the app. I also needed to do this to work around the style sheet having higher priority than programmatically set colours as per my misunderstanding in https://bugs.openjdk.org/browse/JDK-8317434 So I see value in having Color implement something like this. Scott On Dec 11, 2023, at 4:19?PM, Eran Leshem wrote: ?Thank you for your responses. Given that the framework requires colors in string format in its style APIs, I think it should provide some way to convert colors to strings as expected by these APIs. Otherwise, clients are forced to implement this bridging logic on their own, due to a framework gap. And given that Color already parses these string representations, I think it makes sense for it to provide the inverse conversion. Eran -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-retn at openjdk.org] On Behalf Of John Hendrikx Sent: Saturday, December 09, 2023 11:35 PM To: openjfx-dev at openjdk.org Subject: Re: Converting a Color object to its string representation I think this is too niche to have Color provide. Just make a utility method for whatever format you desire, instead of making Color responsible for half a dozen ways of formatting colors, and then probably still missing some format that someone needs. Ticket should be closed as won't fix. --John On 09/12/2023 22:06, Michael Strau? wrote: I obviously meant to write withPrefix("#"), not withDelimiter("#")... On Sat, Dec 9, 2023 at 9:57?PM Michael Strau? wrote: How would HexFormat work with Color, other than using an extremely unwieldy syntax? String formatted = HexFormat.of() .withDelimiter("#") .formatHex(new byte[] { (byte)(color.getRed() * 255.0f), (byte)(color.getGreen() * 255.0f), (byte)(color.getBlue() * 255.0f), (byte)(color.getOpacity() * 255.0f) }); On Sat, Dec 9, 2023 at 9:40?PM David Alayachew wrote: Apologies - java.util.HexFormat That's what I get for firing from the hip, then looking afterwards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at status6.com Sat Dec 16 20:10:39 2023 From: john at status6.com (John Neffenger) Date: Sat, 16 Dec 2023 12:10:39 -0800 Subject: The crisp fonts saga In-Reply-To: References: <278c73515293b33d73bd2e49701b95127722e5e3.camel@io7m.com> <2798dc71-c53c-4b83-d7a6-cb3bbd51de4e@gmail.com> Message-ID: <4a06197f-ca2e-401d-8bf4-b996e8ca7c79@status6.com> On 12/16/23 3:30 AM, Mark Raynsford wrote: > I have, yes. I actually considered properties for each of these, but I > thought it more important to be able to specify them on a node-by-node > basis. I would prefer not to have the tyranny of the project default replaced with a new tyranny of the app default. :-) Wouldn't it be nice to allow developers and end users to enable hinting for any JavaFX application just by defining a system property? Bonus: JavaFX doesn't include its system properties in the API documentation yet, and there's no guarantees made that they won't change, so you're kind of off the hook on documentation, too. > Of course, I could always do both, as with the way font smoothing is > right now (prism.lcdtext and -fx-font-smoothing-type: gray). :) Would you consider splitting it into two enhancement requests? The first could propose the global properties, and a second could allow the developer to set them node by node. You may know much of this already, but for what it's worth, below are some suggestions based on my own experience. For all the reasons mentioned in Phil's message, text rendering issues are in their own special category, regardless of the project. They can be a tough sell, so the burden is on the reporter to provide overwhelming evidence, preferably with text and images all on one page. It helps to go big with any "before" and "after" screenshots: 800 percent minimum, 400 percent for a retina display, with "smoothing" disabled for the image zoom. If at all possible, do what you can to take the issue out of the realm of opinions, where it's often dismissed outright. For example, see . The template below is a good format for enhancement requests. I find it's better to be too formal than too causal. You could post it all on one page, with images inline, somewhere on GitHub. JEP Template https://openjdk.org/jeps/2 See also, of course: Contributing to OpenJFX https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md John From org.openjdk at io7m.com Sat Dec 16 22:02:20 2023 From: org.openjdk at io7m.com (Mark Raynsford) Date: Sat, 16 Dec 2023 22:02:20 +0000 Subject: The crisp fonts saga In-Reply-To: <4a06197f-ca2e-401d-8bf4-b996e8ca7c79@status6.com> References: <278c73515293b33d73bd2e49701b95127722e5e3.camel@io7m.com> <2798dc71-c53c-4b83-d7a6-cb3bbd51de4e@gmail.com> <4a06197f-ca2e-401d-8bf4-b996e8ca7c79@status6.com> Message-ID: On Sat, 2023-12-16 at 12:10 -0800, John Neffenger wrote: > > I would prefer not to have the tyranny of the project default > replaced > with a new tyranny of the app default. :-) > > Wouldn't it be nice to allow developers and end users to enable > hinting > for any JavaFX application just by defining a system property? That is a good point. I had forgotten that most applications don't allow the user to specify their own CSS. What's the expected precedence? I assume it's: * If the CSS specifies a setting, and the corresponding property isn't set, the CSS wins. * If the property specifies a setting, and the CSS isn't set, the property wins. * If the CSS specifies a setting, and the corresponding property specifies a setting, the property wins. > > Of course, I could always do both, as with the way font smoothing > > is > > right now (prism.lcdtext and -fx-font-smoothing-type: gray). :) > > Would you consider splitting it into two enhancement requests? The > first > could propose the global properties, and a second could allow the > developer to set them node by node. I'm pretty discouraged in the sense of getting things upstream. I've watched the project turn away contributors for years now, sadly. I'll definitely be implementing this in separate pieces, so the patches will be available for consideration afterwards. > It helps to go big with any "before" and "after" screenshots: 800 > percent minimum, 400 percent for a retina display, with "smoothing" > disabled for the image zoom. If at all possible, do what you can to > take > the issue out of the realm of opinions, where it's often dismissed > outright. For example, see > . I can definitely do this. -- Mark Raynsford | https://www.io7m.com From tsayao at openjdk.org Sat Dec 16 22:24:49 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 16 Dec 2023 22:24:49 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v2] In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 20:19:12 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > remove compile-time if checks modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c line 197: > 195: return TRUE; > 196: } > 197: return FALSE; I did try to test on Ubuntu 16.04 and compilation failed (no surprise because `GdkSeat` does not exists there). Suggestion to keep `#ifdef` here and `return FALSE` on `#else` so it would still compile on Ubuntu 16.04 and older systems. Will need to `#ifdef` all `GdkSeat` usage. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1305#discussion_r1428953396 From tsayao at openjdk.org Sat Dec 16 22:59:03 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 16 Dec 2023 22:59:03 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v14] In-Reply-To: References: Message-ID: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) 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 88 commits: - - Use a work-around to relative positioning (until wayland is not officially supported) - Unref pango attr list - Merge branch 'master' into new_ime - Account the case of !filtered - Fix change of focus when on preedit + add filter on key release - Merge branch 'master' into new_ime - Remove unused include - Make it a default method for compatibility - Fix JavaDoc - Fix @Override - Forgot one check - ... and 78 more: https://git.openjdk.org/jfx/compare/8872f7af...ba03adce ------------- Changes: https://git.openjdk.org/jfx/pull/1080/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=13 Stats: 462 lines in 7 files changed: 72 ins; 291 del; 99 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From tsayao at openjdk.org Sat Dec 16 22:59:06 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 16 Dec 2023 22:59:06 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v13] In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 19:01:25 GMT, Martin Fox wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Account the case of !filtered > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java line 681: > >> 679: public double[] getInputMethodCandidateRelativePos(int offset) { >> 680: Point2D p2d = scene.inputMethodRequests.getTextLocationRelative(offset); >> 681: return new double[] { p2d.getX(), p2d.getY() }; > > On my system the IM window is incorrectly positioned. This appears to be because I'm running a high-DPI display with 200% magnification. I think you need to call getPlatformScaleX and getPlatformScaleY and apply those scaling factors before passing these coordinates on to glass. You'll see other places in this file where conversions like that are being performed. I did revert the relative positioning change as it will get in the way of merging this. Could you check if it's correctly positioned now? I don't own a fancy monitor :) Tried 200% scale here and everything looks monstrous. 125% scale looks correct. > modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 67: > >> 65: } while (pango_attr_iterator_next(iter)); >> 66: >> 67: pango_attr_iterator_destroy (iter); > > According to the docs you need to release the attribute list using pango_attr_list_unref(). You're right. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1428963127 PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1428962734 From tsayao at openjdk.org Sat Dec 16 23:51:56 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 16 Dec 2023 23:51:56 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v13] In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 19:22:49 GMT, Martin Fox wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Account the case of !filtered > > modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 486: > >> 484: CHECK_JNI_EXCEPTION(mainEnv) >> 485: >> 486: if (press && key > 0) { // TYPED events should only be sent for printable characters. > > A handler for the PRESS event might close the window. In that case `jview` will be set to zero before you send out the TYPED event. You should do another check for that here. > > See [JDK-8301219](https://bugs.openjdk.org/browse/JDK-8301219) for some sample code. I'll be submitting a fix for that bug just as soon as I get a test case working reliably. There's a check before. if (!jview) { return; } ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1428971893 From tsayao at openjdk.org Sat Dec 16 23:59:04 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 16 Dec 2023 23:59:04 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v15] In-Reply-To: References: Message-ID: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: - Fix double keyrelease ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1080/files - new: https://git.openjdk.org/jfx/pull/1080/files/ba03adce..ceb054a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=14 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=13-14 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From tsayao at openjdk.org Sun Dec 17 11:08:56 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 17 Dec 2023 11:08:56 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v13] In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 19:11:27 GMT, Martin Fox wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Account the case of !filtered > > modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 175: > >> 173: if (im_ctx.ctx != NULL) { >> 174: g_signal_handlers_disconnect_matched(im_ctx.ctx, G_SIGNAL_MATCH_DATA, 0, 0, NULL, NULL, NULL); >> 175: g_object_unref(im_ctx.ctx); > > If the IM window is visible when the window is closed disableIME() can get called twice; I'm seeing debug output being generated. Set im_ctx.ctx to NULL here or you'll unref it twice. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1429125936 From tsayao at openjdk.org Sun Dec 17 11:14:56 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 17 Dec 2023 11:14:56 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v13] In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 19:09:44 GMT, Martin Fox wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Account the case of !filtered > > modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 120: > >> 118: if (!filtered || (filtered && im_ctx.send_keypress)) { >> 119: process_key(&event->key); >> 120: im_ctx.send_keypress = false; > > I'm seeing two RELEASE events on each keystroke. If you call process_key() here you need to set `filtered` to true to ensure the event isn't processed again. I changed to "if not filtered", just propagate. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1429127179 From tsayao at openjdk.org Sun Dec 17 11:19:09 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 17 Dec 2023 11:19:09 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v16] In-Reply-To: References: Message-ID: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: - Fix comment path ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1080/files - new: https://git.openjdk.org/jfx/pull/1080/files/ceb054a0..d6622260 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=15 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=14-15 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From jvos at openjdk.org Sun Dec 17 11:32:50 2023 From: jvos at openjdk.org (Johan Vos) Date: Sun, 17 Dec 2023 11:32:50 GMT Subject: [jfx17u] RFR: 8299968: Second call to Stage.setScene() create sizing issue with uiScale > 1.0 [v2] In-Reply-To: References: Message-ID: On Tue, 5 Dec 2023 18:45:11 GMT, Jose Pereda wrote: >> Backport of 8299968: Second call to Stage.setScene() create sizing issue with uiScale > 1.0 >> >> Reviewed-by: kcr, arapte >> >> The backport didn't pass the pre-submit tests: The added test in JDK-8299968 (`SetSceneScalingTest`) was using some methods from `/tests/system/src/test/java/test/util/Util.java` that weren't back ported yet. >> >> Those methods were added in https://bugs.openjdk.org/browse/JDK-8206430, with a commit that modified 101 files. In order to avoid backporting all those files as well, this backport only cherry-picks the changes done to `Util.java` in such commit. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Apply required changes from JDK-8206430 Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/171#pullrequestreview-1785424287 From thiago.sayao at gmail.com Sun Dec 17 11:47:10 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Sun, 17 Dec 2023 08:47:10 -0300 Subject: Unicode characters on JavaFx with latest Ubuntu Message-ID: Hi, I've reported this bug: https://bugs.openjdk.org/browse/JDK-8322251 Unicode characters are being displayed as "generic squares" on JavaFx on Ubuntu 23.10. Any ideas where I should look into it? -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpereda at openjdk.org Sun Dec 17 12:02:53 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 17 Dec 2023 12:02:53 GMT Subject: [jfx17u] Integrated: 8299968: Second call to Stage.setScene() create sizing issue with uiScale > 1.0 In-Reply-To: References: Message-ID: On Tue, 5 Dec 2023 12:03:10 GMT, Jose Pereda wrote: > Backport of 8299968: Second call to Stage.setScene() create sizing issue with uiScale > 1.0 > > Reviewed-by: kcr, arapte > > The backport didn't pass the pre-submit tests: The added test in JDK-8299968 (`SetSceneScalingTest`) was using some methods from `/tests/system/src/test/java/test/util/Util.java` that weren't back ported yet. > > Those methods were added in https://bugs.openjdk.org/browse/JDK-8206430, with a commit that modified 101 files. In order to avoid backporting all those files as well, this backport only cherry-picks the changes done to `Util.java` in such commit. This pull request has now been integrated. Changeset: 7a4fff07 Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/7a4fff075f0c9e5767f1ff73977042b82e857561 Stats: 356 lines in 9 files changed: 349 ins; 4 del; 3 mod 8299968: Second call to Stage.setScene() create sizing issue with uiScale > 1.0 Reviewed-by: jvos Backport-of: 4051f1611646400b59ee871fb40399b933361ba2 ------------- PR: https://git.openjdk.org/jfx17u/pull/171 From jpereda at openjdk.org Sun Dec 17 12:18:56 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 17 Dec 2023 12:18:56 GMT Subject: [jfx17u] RFR: 8260528: Clean glass-gtk sizing and positioning code Message-ID: <4VT0tzcOOhtct0vNkrvLTh4mihyLB3EcVkWnRElk0yg=.30c98418-f1b6-4d59-86cf-718bfb041129@github.com> Clean backport of 8260528: Clean glass-gtk sizing and positioning code Reviewed-by: jvos, kcr ------------- Commit messages: - 8260528: Clean glass-gtk sizing and positioning code Changes: https://git.openjdk.org/jfx17u/pull/172/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=172&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8260528 Stats: 750 lines in 5 files changed: 175 ins; 434 del; 141 mod Patch: https://git.openjdk.org/jfx17u/pull/172.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/172/head:pull/172 PR: https://git.openjdk.org/jfx17u/pull/172 From jpereda at openjdk.org Sun Dec 17 12:40:50 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 17 Dec 2023 12:40:50 GMT Subject: [jfx17u] Integrated: 8260528: Clean glass-gtk sizing and positioning code In-Reply-To: <4VT0tzcOOhtct0vNkrvLTh4mihyLB3EcVkWnRElk0yg=.30c98418-f1b6-4d59-86cf-718bfb041129@github.com> References: <4VT0tzcOOhtct0vNkrvLTh4mihyLB3EcVkWnRElk0yg=.30c98418-f1b6-4d59-86cf-718bfb041129@github.com> Message-ID: <0JgyuVoTuk9JJT63yjq9dZa405oFEmBHGfoaFPEpU5M=.62d8861e-bf37-4a3e-8815-2d732f570cbc@github.com> On Sun, 17 Dec 2023 12:14:03 GMT, Jose Pereda wrote: > Clean backport of 8260528: Clean glass-gtk sizing and positioning code > Reviewed-by: jvos, kcr This pull request has now been integrated. Changeset: 84c2bd93 Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/84c2bd935f136b2d562d48cd135f6903f2d13051 Stats: 750 lines in 5 files changed: 175 ins; 434 del; 141 mod 8260528: Clean glass-gtk sizing and positioning code Backport-of: 0c03a411655047a393862eda937408aa90fc3fa9 ------------- PR: https://git.openjdk.org/jfx17u/pull/172 From jpereda at openjdk.org Sun Dec 17 12:46:02 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 17 Dec 2023 12:46:02 GMT Subject: [jfx17u] RFR: 8251240: Menus inaccessible on Linux with i3 wm Message-ID: Clean backport of 8251240: Menus inaccessible on Linux with i3 wm Reviewed-by: jpereda, jvos ------------- Commit messages: - 8251240: Menus inaccessible on Linux with i3 wm Changes: https://git.openjdk.org/jfx17u/pull/173/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=173&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8251240 Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jfx17u/pull/173.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/173/head:pull/173 PR: https://git.openjdk.org/jfx17u/pull/173 From jpereda at openjdk.org Sun Dec 17 13:25:49 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 17 Dec 2023 13:25:49 GMT Subject: [jfx17u] Integrated: 8251240: Menus inaccessible on Linux with i3 wm In-Reply-To: References: Message-ID: On Sun, 17 Dec 2023 12:40:49 GMT, Jose Pereda wrote: > Clean backport of 8251240: Menus inaccessible on Linux with i3 wm > Reviewed-by: jpereda, jvos This pull request has now been integrated. Changeset: b7e3871c Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/b7e3871c5ac5126efd0ec4bab3aec9131f3fb3f1 Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod 8251240: Menus inaccessible on Linux with i3 wm Backport-of: f18597430d44f70086364170f7bb1e5d30e7ce56 ------------- PR: https://git.openjdk.org/jfx17u/pull/173 From john.hendrikx at gmail.com Sun Dec 17 14:49:20 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sun, 17 Dec 2023 15:49:20 +0100 Subject: The crisp fonts saga In-Reply-To: References: <278c73515293b33d73bd2e49701b95127722e5e3.camel@io7m.com> <2798dc71-c53c-4b83-d7a6-cb3bbd51de4e@gmail.com> <4a06197f-ca2e-401d-8bf4-b996e8ca7c79@status6.com> Message-ID: <25886533-a679-83a7-1d88-f74c2fdbe44c@gmail.com> On 16/12/2023 23:02, Mark Raynsford wrote: > On Sat, 2023-12-16 at 12:10 -0800, John Neffenger wrote: >> I would prefer not to have the tyranny of the project default >> replaced >> with a new tyranny of the app default. :-) >> >> Wouldn't it be nice to allow developers and end users to enable >> hinting >> for any JavaFX application just by defining a system property? > That is a good point. I had forgotten that most applications don't > allow the user to specify their own CSS. > > What's the expected precedence? I assume it's: > > * If the CSS specifies a setting, and the corresponding property isn't > set, the CSS wins. > * If the property specifies a setting, and the CSS isn't set, the > property wins. > * If the CSS specifies a setting, and the corresponding property > specifies a setting, the property wins. It should be INLINE > AUTHOR > USER > USER_AGENT (see StyleOrigin) This means that `setStyle` wins over `getStyleSheets().add`, which wins over a property set by the developer which wins over the default FX Stylesheet. However, there is a bug there. If you set a property at any time, it will override the value.? If however an Author Stylesheet CSS is applied afterwards, it will override the property again. It effectively makes AUTHOR and USER the same level, last one wins... --John From andrea.vacondio at gmail.com Sun Dec 17 15:05:07 2023 From: andrea.vacondio at gmail.com (Andrea Vacondio) Date: Sun, 17 Dec 2023 16:05:07 +0100 Subject: Unicode characters on JavaFx with latest Ubuntu In-Reply-To: References: Message-ID: I had a similar issue with korean and for me it was just a matter of installing Nanum font Il giorno dom 17 dic 2023 alle ore 12:48 Thiago Milczarek Say?o < thiago.sayao at gmail.com> ha scritto: > Hi, > > I've reported this bug: > https://bugs.openjdk.org/browse/JDK-8322251 > > Unicode characters are being displayed as "generic squares" on JavaFx on > Ubuntu 23.10. > > Any ideas where I should look into it? > > -- Thiago. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Sun Dec 17 15:14:15 2023 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 17 Dec 2023 17:14:15 +0200 Subject: The crisp fonts saga In-Reply-To: <25886533-a679-83a7-1d88-f74c2fdbe44c@gmail.com> References: <278c73515293b33d73bd2e49701b95127722e5e3.camel@io7m.com> <2798dc71-c53c-4b83-d7a6-cb3bbd51de4e@gmail.com> <4a06197f-ca2e-401d-8bf4-b996e8ca7c79@status6.com> <25886533-a679-83a7-1d88-f74c2fdbe44c@gmail.com> Message-ID: > This means that `setStyle` wins over `getStyleSheets().add`, which wins over a property set by the developer which wins over the default FX Stylesheet. And binding a property wins even more. On Sun, Dec 17, 2023, 16:49 John Hendrikx wrote: > > On 16/12/2023 23:02, Mark Raynsford wrote: > > On Sat, 2023-12-16 at 12:10 -0800, John Neffenger wrote: > >> I would prefer not to have the tyranny of the project default > >> replaced > >> with a new tyranny of the app default. :-) > >> > >> Wouldn't it be nice to allow developers and end users to enable > >> hinting > >> for any JavaFX application just by defining a system property? > > That is a good point. I had forgotten that most applications don't > > allow the user to specify their own CSS. > > > > What's the expected precedence? I assume it's: > > > > * If the CSS specifies a setting, and the corresponding property isn't > > set, the CSS wins. > > * If the property specifies a setting, and the CSS isn't set, the > > property wins. > > * If the CSS specifies a setting, and the corresponding property > > specifies a setting, the property wins. > > It should be INLINE > AUTHOR > USER > USER_AGENT (see StyleOrigin) > > This means that `setStyle` wins over `getStyleSheets().add`, which wins > over a property set by the developer which wins over the default FX > Stylesheet. > > However, there is a bug there. If you set a property at any time, it > will override the value. If however an Author Stylesheet CSS is applied > afterwards, it will override the property again. It effectively makes > AUTHOR and USER the same level, last one wins... > > --John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at status6.com Sun Dec 17 20:49:08 2023 From: john at status6.com (John Neffenger) Date: Sun, 17 Dec 2023 12:49:08 -0800 Subject: The crisp fonts saga In-Reply-To: References: Message-ID: <0b964c46-b106-4cf4-a16c-1edfd0375ebd@status6.com> On 12/12/23 6:10 AM, Mark Raynsford wrote: > I've never been particularly satisfied with the font rendering in > JavaFX. I looked over the images in your original message. Thank you for taking the time to run all of these experiments! I've included my comments below. I opened the images in separate browser tabs so that I could flip back and forth quickly between each pair. When enabling hints, the choice of font and the FreeType version start to matter. The only recommendation from FreeType I found is: https://freetype.org/freetype2/docs/hinting/subpixel-hinting.html "PS: I recommend using the Liberation family of fonts (version 2 and up, important!) instead of Arial, Times New Roman, and Courier. The family harmonizes much better internally and is equipped with much better ClearType-ready hinting." > For reference, here's how text rendered at 16px using Terminus TTF > looks today: > https://ataxia.io7m.com/2023/12/12/hinting_nobitmaps_normal.png I think that link should be: https://ataxia.io7m.com/2023/12/12/nohinting_nobitmaps_normal.png That's the current unhinted JavaFX rendering. I guess I'm used to it, so it doesn't bother me so much, but I admit it does clash with the slightly-hinted fonts on the rest of my Ubuntu system. > Here's FT_LOAD_RENDER | FT_LOAD_NO_BITMAP (no bitmaps, but using > hinting data): > https://ataxia.io7m.com/2023/12/12/hinting_nobitmaps_normal.png I can't see the difference. Even if the font has no native hints, FreeType should be using the auto-hinter for vertical-only hinting. Maybe you could double-check your "nohinting" and "hinting" screenshots for the "_nobitmaps_normal.png" images. > That's no real improvement. Here's FT_LOAD_RENDER | FT_LOAD_NO_HINTING > (ignore hinting data, but use bitmaps if they are included): > https://ataxia.io7m.com/2023/12/12/nohinting_bitmaps_normal.png These are in fact "crisp" with the bitmaps. It's not my preference, but it is a big difference. > Let's try including both hinting and bitmaps (FT_LOAD_RENDER): > https://ataxia.io7m.com/2023/12/12/hinting_bitmaps_normal.png As you found, it seems that hinting in this case has no effect when using bitmaps. > Here's the JavaFX default (FT_LOAD_NO_HINTING | FT_LOAD_NO_BITMAP): > https://ataxia.io7m.com/2023/12/12/droid_12_nohinting_nobitmaps.png I agree this doesn't look very good at such a small font size. > That's pretty nasty. Let's enable hinting (FT_LOAD_NO_BITMAP): > https://ataxia.io7m.com/2023/12/12/droid_12_hinting_nobitmaps.png Here you can really see the effect of the slight vertical-only hinting. I see movement between the two images in only the vertical direction, but those small changes make a difference. Notice that the "F" in File, the "E" in Edit, and the small "e" all look better. It's rather subtle, but I think these two images make the case for allowing hinting in JavaFX, at least on Linux. > For completeness, let's allow bitmaps: > https://ataxia.io7m.com/2023/12/12/droid_12_hinting_bitmaps.png Droid Sans must not have any bitmaps, so it's the same as before. > Here's the JavaFX default of (FT_LOAD_NO_HINTING | FT_LOAD_NO_BITMAP) > combined with FT_LOAD_TARGET_MONO: > https://ataxia.io7m.com/2023/12/12/droid_12_nohinting_nobitmaps_mono.png Here, you've removed the anti-aliasing, so I agree it looks bad -- probably the worst of all the images. > However, what happens if we enable hinting? > Here's (FT_LOAD_NO_BITMAP | FT_LOAD_TARGET_MONO): > https://ataxia.io7m.com/2023/12/12/droid_12_hinting_nobitmaps_mono.png I'm surprised not to see full hinting here. I see only vertical hinting applied. Maybe the native hinting in the font itself only has vertical hints at this size? > Amusingly, here's DejaVu Sans at 7pt, (FT_LOAD_NO_BITMAP | > FT_LOAD_TARGET_MONO): > https://ataxia.io7m.com/2023/12/12/dejavu_12_hinting_nobitmaps_mono.png It looks as if FreeType is now applying the full horizontal and vertical hinting. The FreeType API documentation says that full hinting is applied when using FT_LOAD_TARGET_MONO, but it switches to slight vertical-only hinting when using FT_LOAD_TARGET_LCD (version 2.8 or later) because it can triple the horizontal resolution with the subpixel rendering. The horizontal hinting here, though, destroys the letter spacing in each of the words. Perhaps the font's native hints aren't very good, it's using the auto-hinter, or it's just such a tiny font size that the hints don't have enough pixels to work with. > That, to my eyes, looks pretty good. The JavaFX defaults for the same > font are not good: > https://ataxia.io7m.com/2023/12/12/dejavu_12_nohinting_nobitmaps_normal.png Here we disagree. At this point size, I'll take no hinting over full hinting. The main difference between these two images, though, is the anti-aliasing, not the hinting. > * Would JavaFX accept patches to allow hinting, bitmaps, and > FT_LOAD_TARGET_MONO? I guess the only problem with FT_LOAD_TARGET_MONO is that you then enable all the bad full native hinting found in most fonts. The FreeType API documentation says: https://freetype.org/freetype2/docs/reference/ft2-glyph_retrieval.html#ft_load_target_xxx "Note that for outline fonts, only the TrueType font driver has proper monochrome hinting support, provided the TTFs contain hints for B/W rendering (which most fonts no longer provide). If these conditions are not met it is very likely that you get ugly results at smaller sizes." Personally, I don't think FT_LOAD_TARGET_MONO is worth the effort when larger font sizes, better-hinted fonts, and even better monitors are so readily available. Same goes for the bitmap fonts. As a first step, I would prefer to have a single property to enable hinting globally so that people could experiment with that for a year or so before adding any other complications to the mix. That gives us the chance to get feedback and build a consensus on possibly, eventually, changing the default of that single setting. John From john at status6.com Sun Dec 17 22:47:17 2023 From: john at status6.com (John Neffenger) Date: Sun, 17 Dec 2023 14:47:17 -0800 Subject: The crisp fonts saga In-Reply-To: <0b964c46-b106-4cf4-a16c-1edfd0375ebd@status6.com> References: <0b964c46-b106-4cf4-a16c-1edfd0375ebd@status6.com> Message-ID: <15914a0b-86a8-4d69-ae7f-6b456d294bf0@status6.com> On 12/17/23 12:49 PM, John Neffenger wrote: >> That's pretty nasty. Let's enable hinting (FT_LOAD_NO_BITMAP): >> https://ataxia.io7m.com/2023/12/12/droid_12_hinting_nobitmaps.png > > Here you can really see the effect of the slight vertical-only hinting. I zoomed in on the images, and seeing no color fringes, I now realize that you ran the tests with FT_LOAD_TARGET_NORMAL instead of the default FT_LOAD_TARGET_LCD. You did mention that you would "assume" the NORMAL setting, but I missed that you actually ran the tests that way. So the vertical-only hinting is not due to the change in FreeType 2.8 for FT_LOAD_TARGET_LCD. It's some other reason -- perhaps due to the hints themselves. This is now beyond my level of competence. :-) All the more reason to change just one setting at a time. Just letting people enable hinting introduces all these variables: - native hinter vs. auto-hinter, - native OpenType/CFF driver vs. native TrueType driver, - whether the native driver and font both support vertical-grid-only-snapping, - the font choice itself and the quality of its hints. It's enough to make your head spin. No single developer could possibly test all this, and it makes a small set of examples almost worthless. Nevertheless, we know it can work because the JDK has enabled hinting for years, if not decades, so maybe just one step at a time. Otherwise, we could be swamped with such a confusion of feedback that it would be impossible to interpret it all. John From martin at martinfox.com Mon Dec 18 00:39:36 2023 From: martin at martinfox.com (Martin Fox) Date: Sun, 17 Dec 2023 16:39:36 -0800 Subject: Issues running SwingNodeJDialogTest on Linux In-Reply-To: References: <5BB0A51E-012F-46A6-8B95-D8CA1BCCC070@martinfox.com> Message-ID: I was running the tests using the default JDK 19 supplied by Ubuntu. In that environment AWT loads GTK 2 and then JavaFX throws an exception. The hang occurs after the test times out. The cleanup code calls Util.shutdown() which eventually calls into Platform.runLater(). The code in PlatformImpl.java then waits forever on the startupLatch which will never reach zero because of the exception thrown earlier. I switched to Java SE 19 where AWT loads GTK 3, JavaFX has no complaints, and the test proceeds. Thanks, Martin > On Dec 15, 2023, at 1:35?PM, Kevin Rushforth wrote: > > Hmm. That's odd. you could pass "-Djdk.gtk.verbose=true" and see what's happening on the GTK loading side. Both AWT and JavaFX will print some info if that system property it set. > > To find out where the test process is hung you can use "jstack PID". If the test itself is hung, then that test would be a good candidate for adding a timeout parameter to the "@Test" tag. > > -- Kevin > > > On 12/15/2023 11:36 AM, Martin Fox wrote: >> I?m having an issue with one of the robot tests on my Linux machine. Before I dig any further I could use some guidance on where to look. >> >> I?m running Ubuntu 22.04 on ARM64 (in a Parallels VM). The command line I?m using is: >> >> bash ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests SwingNodeJDialogTest >> >> The truly puzzling behavior is that the test never stops executing. I?ve got it running right now and it says it?s been executing for over 40 minutes. Shouldn?t the testing framework time this out? >> >> Under the hood I believe that the Glass code in launcher.c is detecting that a GTK 2 library is already loaded so it bails. From what I can tell both JavaFX and Swing should default to GTK 3 so that?s also puzzling. >> >> Any help would be appreciated. >> >> Thanks, >> Martin > From jpereda at openjdk.org Mon Dec 18 09:48:53 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 18 Dec 2023 09:48:53 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v2] In-Reply-To: References: Message-ID: On Sat, 16 Dec 2023 22:21:55 GMT, Thiago Milczarek Sayao wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> remove compile-time if checks > > modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c line 197: > >> 195: return TRUE; >> 196: } >> 197: return FALSE; > > I did try to test on Ubuntu 16.04 and compilation failed (no surprise because `GdkSeat` does not exists there). Suggestion to keep `#ifdef` here and `return FALSE` on `#else` so it would still compile on Ubuntu 16.04 and older systems. Will need to `#ifdef` all `GdkSeat` usage. I take `GdkSeat` is available since GTK 3.0? https://docs.gtk.org/gdk3/class.Seat.html But don't we have a minimum set on 3.8.0? Would this work? #if GTK_CHECK_VERSION(3, 0, 0) static GdkSeat * (*_gdk_display_get_default_seat) (GdkDisplay *display); GdkSeat * wrapped_gdk_display_get_default_seat (GdkDisplay *display) {...} #endif ... #if GTK_CHECK_VERSION(3, 0, 0) GdkSeat* seat = wrapped_gdk_display_get_default_seat(gdk_window_get_display(window)); if (seat != NULL && _gdk_seat_grab != NULL) { *status = ... return TRUE; } #endif ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1305#discussion_r1429810712 From tsayao at openjdk.org Mon Dec 18 10:06:54 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 18 Dec 2023 10:06:54 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v2] In-Reply-To: References: Message-ID: On Mon, 18 Dec 2023 09:46:23 GMT, Jose Pereda wrote: >> modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c line 197: >> >>> 195: return TRUE; >>> 196: } >>> 197: return FALSE; >> >> I did try to test on Ubuntu 16.04 and compilation failed (no surprise because `GdkSeat` does not exists there). Suggestion to keep `#ifdef` here and `return FALSE` on `#else` so it would still compile on Ubuntu 16.04 and older systems. Will need to `#ifdef` all `GdkSeat` usage. > > I take `GdkSeat` is available since GTK 3.0? https://docs.gtk.org/gdk3/class.Seat.html > > But don't we have a minimum set on 3.8.0? > > Would this work? > > #if GTK_CHECK_VERSION(3, 0, 0) > static GdkSeat * (*_gdk_display_get_default_seat) (GdkDisplay *display); > GdkSeat * wrapped_gdk_display_get_default_seat (GdkDisplay *display) > {...} > #endif > > ... > > #if GTK_CHECK_VERSION(3, 0, 0) > GdkSeat* seat = wrapped_gdk_display_get_default_seat(gdk_window_get_display(window)); > if (seat != NULL && _gdk_seat_grab != NULL) { > *status = ... > return TRUE; > } > #endif You're right. GdkSeat should be available. Maybe It needs an include? /home/tsayao/jose/jfx/modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c:151:8: error: unknown type name ?GdkSeat? static GdkSeat * (*_gdk_display_get_default_seat) (GdkDisplay *display); This is when compiling on Ubuntu 16.04. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1305#discussion_r1429842823 From thiago.sayao at gmail.com Mon Dec 18 10:12:41 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 18 Dec 2023 07:12:41 -0300 Subject: Compiling Plataform Preferences on Ubuntu 16.04 Message-ID: Hi, I get some compilation errors when building JavaFX on Ubuntu 16.04, which seems related to the newly introduced Platform preferences API. Should we bother to make it work? In file included from /home/tsayao/jose/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp:45:0: /home/tsayao/jose/jfx/modules/javafx.graphics/src/main/native-glass/gtk/PlatformSupport.h:30:7: error: override controls (override/final) only available with -std=c++11 or -std=gnu++11 [-Werror] class PlatformSupport final ^ /home/tsayao/jose/jfx/modules/javafx.graphics/src/main/native-glass/gtk/PlatformSupport.h:35:47: error: defaulted and deleted functions only available with -std=c++11 or -std=gnu++11 [-Werror] PlatformSupport(PlatformSupport const&) = delete; ^ /home/tsayao/jose/jfx/modules/javafx.graphics/src/main/native-glass/gtk/PlatformSupport.h:36:58: error: defaulted and deleted functions only available with -std=c++11 or -std=gnu++11 [-Werror] PlatformSupport& operator=(PlatformSupport const&) = delete; -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsayao at openjdk.org Mon Dec 18 10:12:53 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 18 Dec 2023 10:12:53 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v2] In-Reply-To: References: Message-ID: <_0mP3XCihDpjdPFtZKtWL0TELGWAgx6mYcQbX83XRzY=.09683bed-f6ad-4e24-90df-173fc69eac59@github.com> On Mon, 18 Dec 2023 09:46:23 GMT, Jose Pereda wrote: >> modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c line 197: >> >>> 195: return TRUE; >>> 196: } >>> 197: return FALSE; >> >> I did try to test on Ubuntu 16.04 and compilation failed (no surprise because `GdkSeat` does not exists there). Suggestion to keep `#ifdef` here and `return FALSE` on `#else` so it would still compile on Ubuntu 16.04 and older systems. Will need to `#ifdef` all `GdkSeat` usage. > > I take `GdkSeat` is available since GTK 3.0? https://docs.gtk.org/gdk3/class.Seat.html > > But don't we have a minimum set on 3.8.0? > > Would this work? > > #if GTK_CHECK_VERSION(3, 0, 0) > static GdkSeat * (*_gdk_display_get_default_seat) (GdkDisplay *display); > GdkSeat * wrapped_gdk_display_get_default_seat (GdkDisplay *display) > {...} > #endif > > ... > > #if GTK_CHECK_VERSION(3, 0, 0) > GdkSeat* seat = wrapped_gdk_display_get_default_seat(gdk_window_get_display(window)); > if (seat != NULL && _gdk_seat_grab != NULL) { > *status = ... > return TRUE; > } > #endif I think the docs are wrong, I probably exists since 3.20, so maybe check for `GTK_CHECK_VERSION(3, 20, 0);`. This is the compilation error on Ubuntu 16.04: `/home/tsayao/jose/jfx/modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c:200:34: error: unknown type name ?GdkSeat? ` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1305#discussion_r1429852839 From jpereda at openjdk.org Mon Dec 18 10:22:52 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 18 Dec 2023 10:22:52 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v2] In-Reply-To: <_0mP3XCihDpjdPFtZKtWL0TELGWAgx6mYcQbX83XRzY=.09683bed-f6ad-4e24-90df-173fc69eac59@github.com> References: <_0mP3XCihDpjdPFtZKtWL0TELGWAgx6mYcQbX83XRzY=.09683bed-f6ad-4e24-90df-173fc69eac59@github.com> Message-ID: <0jjTW-5bIJrtf1XohxtlPDtch5_5z3nPUk81Z9zPvhw=.d4777818-ea96-4352-b27a-4994545a9bbc@github.com> On Mon, 18 Dec 2023 10:09:29 GMT, Thiago Milczarek Sayao wrote: >> I take `GdkSeat` is available since GTK 3.0? https://docs.gtk.org/gdk3/class.Seat.html >> >> But don't we have a minimum set on 3.8.0? >> >> Would this work? >> >> #if GTK_CHECK_VERSION(3, 0, 0) >> static GdkSeat * (*_gdk_display_get_default_seat) (GdkDisplay *display); >> GdkSeat * wrapped_gdk_display_get_default_seat (GdkDisplay *display) >> {...} >> #endif >> >> ... >> >> #if GTK_CHECK_VERSION(3, 0, 0) >> GdkSeat* seat = wrapped_gdk_display_get_default_seat(gdk_window_get_display(window)); >> if (seat != NULL && _gdk_seat_grab != NULL) { >> *status = ... >> return TRUE; >> } >> #endif > > I think the docs are wrong, I probably exists since 3.20, so maybe check for `GTK_CHECK_VERSION(3, 20, 0);`. > > > This is the compilation error on Ubuntu 16.04: > `/home/tsayao/jose/jfx/modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c:200:34: error: unknown type name ?GdkSeat? > ` Okay, that is unfortunate (GTK docs inaccurate), but makes sense. I'll add the compile-time checks to `wrapped.c`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1305#discussion_r1429864963 From tsayao at openjdk.org Mon Dec 18 10:31:53 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 18 Dec 2023 10:31:53 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v2] In-Reply-To: <0jjTW-5bIJrtf1XohxtlPDtch5_5z3nPUk81Z9zPvhw=.d4777818-ea96-4352-b27a-4994545a9bbc@github.com> References: <_0mP3XCihDpjdPFtZKtWL0TELGWAgx6mYcQbX83XRzY=.09683bed-f6ad-4e24-90df-173fc69eac59@github.com> <0jjTW-5bIJrtf1XohxtlPDtch5_5z3nPUk81Z9zPvhw=.d4777818-ea96-4352-b27a-4994545a9bbc@github.com> Message-ID: On Mon, 18 Dec 2023 10:20:35 GMT, Jose Pereda wrote: >> I think the docs are wrong, I probably exists since 3.20, so maybe check for `GTK_CHECK_VERSION(3, 20, 0);`. >> >> >> This is the compilation error on Ubuntu 16.04: >> `/home/tsayao/jose/jfx/modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c:200:34: error: unknown type name ?GdkSeat? >> ` > > Okay, that is unfortunate (GTK docs inaccurate), but makes sense. > > I'll add the compile-time checks to `wrapped.c`. But then, using `dlsym` seems redundant, as we can simply call the seat functions directly? The check is to allow compilation and test on Ubuntu 16.04 - When shipping the final build it should be built on gtk 3.20+, so both dlsym and the check makes sense. So when running on Ubuntu 16.04: - For testing on the platform, the #ifdef will make it possible to compile; - For running the released built (which should be built on gtk 3.20+) dlsym will fail and fallback; ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1305#discussion_r1429875706 From tsayao at openjdk.org Mon Dec 18 10:38:52 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 18 Dec 2023 10:38:52 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v2] In-Reply-To: References: <_0mP3XCihDpjdPFtZKtWL0TELGWAgx6mYcQbX83XRzY=.09683bed-f6ad-4e24-90df-173fc69eac59@github.com> <0jjTW-5bIJrtf1XohxtlPDtch5_5z3nPUk81Z9zPvhw=.d4777818-ea96-4352-b27a-4994545a9bbc@github.com> Message-ID: On Mon, 18 Dec 2023 10:29:00 GMT, Thiago Milczarek Sayao wrote: >> Okay, that is unfortunate (GTK docs inaccurate), but makes sense. >> >> I'll add the compile-time checks to `wrapped.c`. But then, using `dlsym` seems redundant, as we can simply call the seat functions directly? > > The check is to allow compilation and test on Ubuntu 16.04 - When shipping the final build it should be built on gtk 3.20+, so both dlsym and the check makes sense. > > So when running on Ubuntu 16.04: > - For testing on the platform, the #ifdef will make it possible to compile; > - For running the released built (which should be built on gtk 3.20+) dlsym will fail and fallback; That's only if we want to keep building working on 16.04. I think it makes easier to test on it. But, it's already failing for Platform preferences API code. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1305#discussion_r1429888067 From jpereda at openjdk.org Mon Dec 18 10:38:53 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 18 Dec 2023 10:38:53 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v2] In-Reply-To: References: <_0mP3XCihDpjdPFtZKtWL0TELGWAgx6mYcQbX83XRzY=.09683bed-f6ad-4e24-90df-173fc69eac59@github.com> <0jjTW-5bIJrtf1XohxtlPDtch5_5z3nPUk81Z9zPvhw=.d4777818-ea96-4352-b27a-4994545a9bbc@github.com> Message-ID: <4n0N17UhDR-g0zwrBSnA8rgAbVzJ6eaEWQHsjR6GUrs=.d701d259-cbc8-4719-a298-b94812afe5b6@github.com> On Mon, 18 Dec 2023 10:34:02 GMT, Thiago Milczarek Sayao wrote: >> The check is to allow compilation and test on Ubuntu 16.04 - When shipping the final build it should be built on gtk 3.20+, so both dlsym and the check makes sense. >> >> So when running on Ubuntu 16.04: >> - For testing on the platform, the #ifdef will make it possible to compile; >> - For running the released built (which should be built on gtk 3.20+) dlsym will fail and fallback; > > That's only if we want to keep building working on 16.04. I think it makes easier to test on it. > But, it's already failing for Platform preferences API code. In any case, if `GdkSeat` is available only since 3.20, then we need to add the compile-time checks anyway, since minimum supported is 3.8. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1305#discussion_r1429891858 From jpereda at openjdk.org Mon Dec 18 11:19:18 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 18 Dec 2023 11:19:18 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: References: Message-ID: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> > This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Add compile-time checks to GdkSeat ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1305/files - new: https://git.openjdk.org/jfx/pull/1305/files/99230ca6..f8ffe87f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1305&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1305&range=01-02 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1305.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1305/head:pull/1305 PR: https://git.openjdk.org/jfx/pull/1305 From jvos at openjdk.org Mon Dec 18 12:11:06 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 18 Dec 2023 12:11:06 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v3] In-Reply-To: References: Message-ID: > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos 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 three additional commits since the last revision: - These changes are related to JBS-8318841 so we want to have that code in as well. Merge branch 'master' into 8319779-systemmenu - process reviewers comments - A listener was added but never removed. This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1283/files - new: https://git.openjdk.org/jfx/pull/1283/files/c7fe11cb..ba840397 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=01-02 Stats: 53018 lines in 578 files changed: 24682 ins; 20433 del; 7903 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From jpereda at openjdk.org Mon Dec 18 12:14:58 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 18 Dec 2023 12:14:58 GMT Subject: RFR: 8321970: New table columns don't appear when using fixed cell size unless refreshing tableView Message-ID: This PR fixes an issue when a new `TableColumn` is added to a `TableView` control with fixed cell size set, where the `TableRowSkinBase` failed to add the cells for the new column. A test is included that fails before applying this PR and passes with it. ------------- Commit messages: - Add cells to tableRow after new columns are added to tableView Changes: https://git.openjdk.org/jfx/pull/1308/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1308&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321970 Stats: 26 lines in 2 files changed: 24 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1308.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1308/head:pull/1308 PR: https://git.openjdk.org/jfx/pull/1308 From jvos at openjdk.org Mon Dec 18 13:18:02 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 18 Dec 2023 13:18:02 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v4] In-Reply-To: References: Message-ID: > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Fix more memoryleaks due to listeners never being unregistered. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1283/files - new: https://git.openjdk.org/jfx/pull/1283/files/ba840397..47f4d65d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=02-03 Stats: 12 lines in 1 file changed: 1 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From jvos at openjdk.org Mon Dec 18 13:21:51 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 18 Dec 2023 13:21:51 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v4] In-Reply-To: References: Message-ID: On Mon, 18 Dec 2023 13:18:02 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Fix more memoryleaks due to listeners never being unregistered. As for the testing issue: the memoryleak before this fix leads to an increasing number of `com.sun.glass.ui.MenuItem` instances. We could test the previous memoryleak, as that was creating an increasing number of `javafx.scene.control.MenuItem` instances, which could be handled inside a JavaFX application and stored as WeakReferences in a list, that could then be required to be empty after GC. Our systemtest does not have access to the `com.sun.glass.ui.MenuItem` instances, so we can't use the same approach. In theory, it should be possible to mock the whole path that leads to this leak, but it is complex. I do understand the value of tests for this, though, as the fix is brittle. When a new InvalidationListener is added referencing the to-be-removed menuItems, the memoryleak will re-occur and go unnoticed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1860481040 From kevin.rushforth at oracle.com Mon Dec 18 14:03:32 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 18 Dec 2023 06:03:32 -0800 Subject: Compiling Plataform Preferences on Ubuntu 16.04 In-Reply-To: References: Message-ID: <0427fc02-4cbd-465e-809c-5b9c05405e46@oracle.com> This is really about gcc rather than a version of Ubuntu. I see little value in making the javafx.graphics native code compile with such an old version of gcc that it doesn't support C++11. (Worth noting that WebKit requires an even newer version, since it uses C++20 features). So, while yes, I'd like to see this continue to be buildable on Ubuntu 16.04 -- and so far I have no problems compiling on that OS -- it seems fine to require a newer compiler in order for you to do so. -- Kevin On 12/18/2023 2:12 AM, Thiago Milczarek Say?o wrote: > Hi, > > I get some compilation errors when building JavaFX on Ubuntu 16.04, > which seems related to the newly introduced Platform preferences API. > > Should we bother to make it work? > > In file included from > /home/tsayao/jose/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp:45:0: > /home/tsayao/jose/jfx/modules/javafx.graphics/src/main/native-glass/gtk/PlatformSupport.h:30:7: > error: override controls (override/final) only available with > -std=c++11 or -std=gnu++11 [-Werror] > ?class PlatformSupport final > ? ? ? ?^ > /home/tsayao/jose/jfx/modules/javafx.graphics/src/main/native-glass/gtk/PlatformSupport.h:35:47: > error: defaulted and deleted functions only available with -std=c++11 > or -std=gnu++11 [-Werror] > ? ? ?PlatformSupport(PlatformSupport const&) = delete; > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ > /home/tsayao/jose/jfx/modules/javafx.graphics/src/main/native-glass/gtk/PlatformSupport.h:36:58: > error: defaulted and deleted functions only available with -std=c++11 > or -std=gnu++11 [-Werror] > ? ? ?PlatformSupport& operator=(PlatformSupport const&) = delete; > > > -- Thiago. From kevin.rushforth at oracle.com Mon Dec 18 14:10:01 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 18 Dec 2023 06:10:01 -0800 Subject: [External] : Re: Issues running SwingNodeJDialogTest on Linux In-Reply-To: References: <5BB0A51E-012F-46A6-8B95-D8CA1BCCC070@martinfox.com> Message-ID: <6dd6927b-78f3-4b31-81f9-122846585389@oracle.com> Glad the problem is understood, and you were able to find a fix. -- Kevin On 12/17/2023 4:39 PM, Martin Fox wrote: > I was running the tests using the default JDK 19 supplied by Ubuntu. In that environment AWT loads GTK 2 and then JavaFX throws an exception. > > The hang occurs after the test times out. The cleanup code calls Util.shutdown() which eventually calls into Platform.runLater(). The code in PlatformImpl.java then waits forever on the startupLatch which will never reach zero because of the exception thrown earlier. > > I switched to Java SE 19 where AWT loads GTK 3, JavaFX has no complaints, and the test proceeds. > > Thanks, > Martin > >> On Dec 15, 2023, at 1:35?PM, Kevin Rushforth wrote: >> >> Hmm. That's odd. you could pass "-Djdk.gtk.verbose=true" and see what's happening on the GTK loading side. Both AWT and JavaFX will print some info if that system property it set. >> >> To find out where the test process is hung you can use "jstack PID". If the test itself is hung, then that test would be a good candidate for adding a timeout parameter to the "@Test" tag. >> >> -- Kevin >> >> >> On 12/15/2023 11:36 AM, Martin Fox wrote: >>> I?m having an issue with one of the robot tests on my Linux machine. Before I dig any further I could use some guidance on where to look. >>> >>> I?m running Ubuntu 22.04 on ARM64 (in a Parallels VM). The command line I?m using is: >>> >>> bash ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests SwingNodeJDialogTest >>> >>> The truly puzzling behavior is that the test never stops executing. I?ve got it running right now and it says it?s been executing for over 40 minutes. Shouldn?t the testing framework time this out? >>> >>> Under the hood I believe that the Glass code in launcher.c is detecting that a GTK 2 library is already loaded so it bails. From what I can tell both JavaFX and Swing should default to GTK 3 so that?s also puzzling. >>> >>> Any help would be appreciated. >>> >>> Thanks, >>> Martin From fastegal at openjdk.org Mon Dec 18 14:16:52 2023 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Mon, 18 Dec 2023 14:16:52 GMT Subject: RFR: 8321970: New table columns don't appear when using fixed cell size unless refreshing tableView In-Reply-To: References: Message-ID: On Mon, 18 Dec 2023 12:09:21 GMT, Jose Pereda wrote: > This PR fixes an issue when a new `TableColumn` is added to a `TableView` control with fixed cell size set, where the `TableRowSkinBase` failed to add the cells for the new column. > > A test is included that fails before applying this PR and passes with it. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java line 87: > 85: tableView.setItems(items); > 86: > 87: stageLoader = new StageLoader(new Scene(tableView)); this changes the context of unrelated tests - no idea whether or not it matters, but I would try not to :) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1308#discussion_r1430196552 From jvos at openjdk.org Mon Dec 18 15:17:13 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 18 Dec 2023 15:17:13 GMT Subject: [jfx17u] Integrated: 8181084: JavaFX show big icons in system menu on macOS with Retina display Message-ID: clean backport of 8181084: JavaFX show big icons in system menu on macOS with Retina di?splay Reviewed-by: jpereda, kcr ------------- Commit messages: - 8181084: JavaFX show big icons in system menu on macOS with Retina display Changes: https://git.openjdk.org/jfx17u/pull/174/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=174&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8181084 Stats: 103 lines in 14 files changed: 97 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jfx17u/pull/174.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/174/head:pull/174 PR: https://git.openjdk.org/jfx17u/pull/174 From jvos at openjdk.org Mon Dec 18 15:17:13 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 18 Dec 2023 15:17:13 GMT Subject: [jfx17u] Integrated: 8181084: JavaFX show big icons in system menu on macOS with Retina display In-Reply-To: References: Message-ID: <0pDnVbZDvZe3aavEJn7RL5V2M7YvnDJOuuoKiMIMsAA=.822e0434-8cef-479d-99f0-4c42f9484cd3@github.com> On Mon, 18 Dec 2023 15:08:58 GMT, Johan Vos wrote: > clean backport of 8181084: JavaFX show big icons in system menu on macOS with Retina di?splay > > Reviewed-by: jpereda, kcr This pull request has now been integrated. Changeset: 9fdfb679 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/9fdfb679891e0f529fdccaea86167d03e8cc3ea7 Stats: 103 lines in 14 files changed: 97 ins; 3 del; 3 mod 8181084: JavaFX show big icons in system menu on macOS with Retina display Backport-of: 2618bf8aeef3c9d9d923576e8a610f5e9b2123f1 ------------- PR: https://git.openjdk.org/jfx17u/pull/174 From jpereda at openjdk.org Mon Dec 18 15:51:01 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 18 Dec 2023 15:51:01 GMT Subject: RFR: 8321970: New table columns don't appear when using fixed cell size unless refreshing tableView [v2] In-Reply-To: References: Message-ID: > This PR fixes an issue when a new `TableColumn` is added to a `TableView` control with fixed cell size set, where the `TableRowSkinBase` failed to add the cells for the new column. > > A test is included that fails before applying this PR and passes with it. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: address feedback ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1308/files - new: https://git.openjdk.org/jfx/pull/1308/files/9c138c49..04cc76b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1308&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1308&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1308.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1308/head:pull/1308 PR: https://git.openjdk.org/jfx/pull/1308 From jpereda at openjdk.org Mon Dec 18 15:51:04 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 18 Dec 2023 15:51:04 GMT Subject: RFR: 8321970: New table columns don't appear when using fixed cell size unless refreshing tableView [v2] In-Reply-To: References: Message-ID: On Mon, 18 Dec 2023 14:13:51 GMT, Jeanette Winzenburg wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> address feedback > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java line 87: > >> 85: tableView.setItems(items); >> 86: >> 87: stageLoader = new StageLoader(new Scene(tableView)); > > this changes the context of unrelated tests - no idea whether or not it matters, but I would try not to :) Good catch, actually this changes is a leftover after some changes I did while getting the test to fail... but now I see it is not needed after all. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1308#discussion_r1430332070 From andy.goryachev at oracle.com Mon Dec 18 16:18:38 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 18 Dec 2023 16:18:38 +0000 Subject: New API: Animation/Timeline improvement In-Reply-To: <1991b717-755e-d44f-9537-99b583b0904a@gmail.com> References: <1991b717-755e-d44f-9537-99b583b0904a@gmail.com> Message-ID: Would making Timeline to use WeakReferences solve the issue without the need for a new API? -andy From: openjfx-dev on behalf of John Hendrikx Date: Friday, December 15, 2023 at 21:53 To: openjfx-dev Subject: New API: Animation/Timeline improvement Hi list, I've noticed that Animations and Timelines are often a source of leaks, and their clean-up is often either non-existent or incorrect. The reason they cause leaks easily is because a running animation or timeline is globally referred from a singleton PrimaryTimer. The animation or timeline then refers to properties or event handlers which refer to controls (which refer to parents and the entire scene). For example: - ScrollBarBehavior uses a Timeline, but neglects to clean it up. If it was running at the time a Scene is detached from a Window, and that Scene is left to go out of scope, it won't because Timeline refers it; this can happen if the behavior never receives a key released event. - ScrollBarBehavior has no dispose method overridden, so swapping Skins while the animation is running will leave a Timeline active (it uses Animation.INDEFINITE) - SpinnerBehavior has flawed clean up; it attaches a Scene listener and disables its timeline when the scene changed, but the scene doesn't have to change for it to go out of scope as a whole... Result is that if you have a spinner timeline running, and you close the entire window (no Scene change happens), the entire Scene will still be referred. It also uses an indefinite cycle count. It also lacks a dispose method, so swapping Skins at a bad moment can also leave a reference. I think these mistakes are common, and far too easy to make. The most common use cases for animations revolve around modifying properties on visible controls, and although animations can be used for purposes other than animating UI controls, this is extremely rare. So it is safe to say that in 99% of cases you want the animation to stop once a some Node is no longer showing. For both the mentioned buggy behaviors above, this would be perfect. A spinner stops spinning when no longer showing, and a scroll bar stops scrolling when no longer showing. It is also likely to apply for many other uses of timelines and animations. I therefore want to propose a new API, either on Node or Animation (or both): /** * Creates a new timeline which is stopped automatically when this Node * is no longer showing. Stopping timelines is essential as they may refer * nodes even after they are no longer used anywhere, preventing them from * being garbage collected. */ Node.createTimeline(); // and variants with the various Timeline constructors And/or: /** * Links this Animation to the given Node, and stops the animation * automatically when the Node is no longer showing. Stopping animations * is essential as they may refer nodes even after they are no longer used * anywhere, preventing them from being garbage collected. */ void stopWhenHidden(Node node); The above API for Animation could also be provided through another constructor, which takes a Node which will it be linked to. Alternatives: - Be a lot more diligent about cleaning up animations and timelines (essentially maintain the status quo which has led to above bugs) - Use this lengthy code fragment below: Timeline timeline = new Timeline(); someNode.sceneProperty() .when(timeline.statusProperty().map(status -> status != Status.STOPPED)) .flatMap(Scene::windowProperty) .flatMap(Window::showingProperty) .orElse(false) .subscribe(showing -> { if (!showing) timeline.stop(); }); The `when` line ensures that the opposite problem (Nodes forever referencing Timelines) doesn't occur if you are creating a new Timeline for each use (not recommended, but nonetheless a common occurrence). --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Mon Dec 18 16:24:50 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Dec 2023 16:24:50 GMT Subject: RFR: 8301219: JavaFX crash when closing with the escape key [v2] In-Reply-To: References: Message-ID: On Fri, 15 Dec 2023 20:57:01 GMT, Martin Fox wrote: >> While processing a key down event the Glass GTK code sends out PRESSED and TYPED KeyEvents back to back. If the stage is closed during the PRESSED event the code will end up referencing freed memory while sending out the TYPED event. This can lead to intermittent crashes. >> >> In GlassApplication.cpp the EventCounterHelper object ensures the WindowContext isn't deleted while processing an event. Currently the helper object is being created *after* IME handling instead of before. If the IME is enabled it's possible for the WindowContext to be deleted in the middle of executing a number of keyboard-related events. >> >> The fix is simple; instantiate the EventCounterHelper object earlier. There isn't always a WindowContext so I tweaked the EventCounterHelper to do nothing if the context is null. >> >> To make the crash more reproducible I altered the WindowContext such that when it's deleted the freed memory is filled with 0xCC. This made the crash more reproducible and allowed me to test the fix. I did the same with GlassView since that's the only other Glass GTK class that's instantiated with `new` and discarded with `delete`. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Debugging code turned off by default. Empty line removed. LGTM now. I did ask one question and will reapprove if you make the change. modules/javafx.graphics/src/main/native-glass/gtk/DeletedMemDebug.h line 46: > 44: static void operator delete[](void* ptr, std::size_t sz) > 45: { > 46: ::memset(ptr, 0xcc, sz); Should this use `FILL` instead of hard-coded `0xcc`? ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1307#pullrequestreview-1786885134 PR Review Comment: https://git.openjdk.org/jfx/pull/1307#discussion_r1430137769 From kevin.rushforth at oracle.com Mon Dec 18 17:24:12 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 18 Dec 2023 09:24:12 -0800 Subject: Proposed schedule for JavaFX 22 In-Reply-To: References: Message-ID: As a reminder, Rampdown Phase 1 (RDP1) for JavaFX 22 starts on Thursday, January 11, 2024 at 16:00 UTC (08:00 US/Pacific time). Given the upcoming holidays, that's a little over 2 working weeks from now. During rampdown of JavaFX 22, the "master" branch of the jfx repo will be open for JavaFX 23 fixes. Please allow sufficient time for any feature that needs a CSR. New features should be far enough along in the review process that you can finalize the CSR no later than Thursday, January 4, or it is likely to miss the window for this release, in which case it can be targeted for JavaFX 23. We will follow the same process as in previous releases for getting fixes into JavaFX 22 during rampdown. I'll send a message with detailed information when we fork, but candidates for fixing during RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc bugs of any priority. Some small enhancements might be considered during RDP1, but they require explicit approval; the bar will be high for such requests. -- Kevin On 9/21/2023 7:41 AM, Kevin Rushforth wrote: > Here is the proposed schedule for JavaFX 22. > > RDP1: Jan 11, 2024 (aka ?feature freeze?) > RDP2: Feb 1, 2024 > Freeze: Feb 29, 2024 > GA: Mar 19, 2024 > > We plan to fork a jfx22 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 mfox at openjdk.org Mon Dec 18 19:15:03 2023 From: mfox at openjdk.org (Martin Fox) Date: Mon, 18 Dec 2023 19:15:03 GMT Subject: RFR: 8301219: JavaFX crash when closing with the escape key [v3] In-Reply-To: References: Message-ID: > While processing a key down event the Glass GTK code sends out PRESSED and TYPED KeyEvents back to back. If the stage is closed during the PRESSED event the code will end up referencing freed memory while sending out the TYPED event. This can lead to intermittent crashes. > > In GlassApplication.cpp the EventCounterHelper object ensures the WindowContext isn't deleted while processing an event. Currently the helper object is being created *after* IME handling instead of before. If the IME is enabled it's possible for the WindowContext to be deleted in the middle of executing a number of keyboard-related events. > > The fix is simple; instantiate the EventCounterHelper object earlier. There isn't always a WindowContext so I tweaked the EventCounterHelper to do nothing if the context is null. > > To make the crash more reproducible I altered the WindowContext such that when it's deleted the freed memory is filled with 0xCC. This made the crash more reproducible and allowed me to test the fix. I did the same with GlassView since that's the only other Glass GTK class that's instantiated with `new` and discarded with `delete`. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Consistent use of FILL in mem debug code. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1307/files - new: https://git.openjdk.org/jfx/pull/1307/files/6a4a4e63..09f8ede5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1307&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1307&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1307.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1307/head:pull/1307 PR: https://git.openjdk.org/jfx/pull/1307 From mfox at openjdk.org Mon Dec 18 19:15:07 2023 From: mfox at openjdk.org (Martin Fox) Date: Mon, 18 Dec 2023 19:15:07 GMT Subject: RFR: 8301219: JavaFX crash when closing with the escape key [v2] In-Reply-To: References: Message-ID: On Mon, 18 Dec 2023 13:22:07 GMT, Kevin Rushforth wrote: >> Martin Fox has updated the pull request incrementally with one additional commit since the last revision: >> >> Debugging code turned off by default. Empty line removed. > > modules/javafx.graphics/src/main/native-glass/gtk/DeletedMemDebug.h line 46: > >> 44: static void operator delete[](void* ptr, std::size_t sz) >> 45: { >> 46: ::memset(ptr, 0xcc, sz); > > Should this use `FILL` instead of hard-coded `0xcc`? Yes, it should use FILL. Will fix. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1307#discussion_r1430550148 From kcr at openjdk.org Mon Dec 18 20:29:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Dec 2023 20:29:49 GMT Subject: RFR: 8301219: JavaFX crash when closing with the escape key [v3] In-Reply-To: References: Message-ID: On Mon, 18 Dec 2023 19:15:03 GMT, Martin Fox wrote: >> While processing a key down event the Glass GTK code sends out PRESSED and TYPED KeyEvents back to back. If the stage is closed during the PRESSED event the code will end up referencing freed memory while sending out the TYPED event. This can lead to intermittent crashes. >> >> In GlassApplication.cpp the EventCounterHelper object ensures the WindowContext isn't deleted while processing an event. Currently the helper object is being created *after* IME handling instead of before. If the IME is enabled it's possible for the WindowContext to be deleted in the middle of executing a number of keyboard-related events. >> >> The fix is simple; instantiate the EventCounterHelper object earlier. There isn't always a WindowContext so I tweaked the EventCounterHelper to do nothing if the context is null. >> >> To make the crash more reproducible I altered the WindowContext such that when it's deleted the freed memory is filled with 0xCC. This made the crash more reproducible and allowed me to test the fix. I did the same with GlassView since that's the only other Glass GTK class that's instantiated with `new` and discarded with `delete`. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Consistent use of FILL in mem debug code. Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1307#pullrequestreview-1787650273 From kcr at openjdk.org Mon Dec 18 21:49:51 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Dec 2023 21:49:51 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v2] In-Reply-To: <4n0N17UhDR-g0zwrBSnA8rgAbVzJ6eaEWQHsjR6GUrs=.d701d259-cbc8-4719-a298-b94812afe5b6@github.com> References: <_0mP3XCihDpjdPFtZKtWL0TELGWAgx6mYcQbX83XRzY=.09683bed-f6ad-4e24-90df-173fc69eac59@github.com> <0jjTW-5bIJrtf1XohxtlPDtch5_5z3nPUk81Z9zPvhw=.d4777818-ea96-4352-b27a-4994545a9bbc@github.com> <4n0N17UhDR-g0zwrBSnA8rgAbVzJ6eaEWQHsjR6GUrs=.d701d259-cbc8-4719-a298-b94812afe5b6@github.com> Message-ID: On Mon, 18 Dec 2023 10:36:32 GMT, Jose Pereda wrote: >> That's only if we want to keep building working on 16.04. I think it makes easier to test on it. >> But, it's already failing for Platform preferences API code. > > In any case, if `GdkSeat` is available only since 3.20, then we need to add the compile-time checks anyway, since minimum supported is 3.8. It seems like this is the best we can do for now. What is means is that we won't be able to build on a system with 3.8 - 3.19 and distribute a library that will use the new functionality when running on 3.20 or later. That's probably OK in this case, but is worth noting. What is important, and why the runtime check is needed (as noted above) is that we can build a production release of JavaFX on a system that has a later GTK and it will run on a system with an older GTK. It won't use the feature on those older systems, but won't crash. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1305#discussion_r1430679284 From kcr at openjdk.org Mon Dec 18 21:53:48 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Dec 2023 21:53:48 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v2] In-Reply-To: References: <_0mP3XCihDpjdPFtZKtWL0TELGWAgx6mYcQbX83XRzY=.09683bed-f6ad-4e24-90df-173fc69eac59@github.com> <0jjTW-5bIJrtf1XohxtlPDtch5_5z3nPUk81Z9zPvhw=.d4777818-ea96-4352-b27a-4994545a9bbc@github.com> <4n0N17UhDR-g0zwrBSnA8rgAbVzJ6eaEWQHsjR6GUrs=.d701d259-cbc8-4719-a298-b94812afe5b6@github.com> Message-ID: <_j9emR0JIqHYoEeAXzunIoBDWwI161s0C-SLBONvzPU=.d38f7d47-03de-400e-b6af-4cf54b35c378@github.com> On Mon, 18 Dec 2023 21:47:05 GMT, Kevin Rushforth wrote: >> In any case, if `GdkSeat` is available only since 3.20, then we need to add the compile-time checks anyway, since minimum supported is 3.8. > > It seems like this is the best we can do for now. What is means is that we won't be able to build on a system with 3.8 - 3.19 and distribute a library that will use the new functionality when running on 3.20 or later. That's probably OK in this case, but is worth noting. > > What is important, and why the runtime check is needed (as noted above) is that we can build a production release of JavaFX on a system that has a later GTK and it will run on a system with an older GTK. It won't use the feature on those older systems, but won't crash. As an FYI, we use GTK 3.22 on our CI build machines so I wouldn't want to see the build-time dependency move any higher than it currently is. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1305#discussion_r1430682992 From tsayao at openjdk.org Mon Dec 18 21:58:47 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 18 Dec 2023 21:58:47 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v2] In-Reply-To: <_j9emR0JIqHYoEeAXzunIoBDWwI161s0C-SLBONvzPU=.d38f7d47-03de-400e-b6af-4cf54b35c378@github.com> References: <_0mP3XCihDpjdPFtZKtWL0TELGWAgx6mYcQbX83XRzY=.09683bed-f6ad-4e24-90df-173fc69eac59@github.com> <0jjTW-5bIJrtf1XohxtlPDtch5_5z3nPUk81Z9zPvhw=.d4777818-ea96-4352-b27a-4994545a9bbc@github.com> <4n0N17UhDR-g0zwrBSnA8rgAbVzJ6eaEWQHsjR6GUrs=.d701d259-cbc8-4719-a298-b94812afe5b6@github.com> <_j9emR0JIqHYoEeAXzunIoBDWwI161s0C-S LBONvzPU=.d38f7d47-03de-400e-b6af-4cf54b35c378@github.com> Message-ID: On Mon, 18 Dec 2023 21:51:13 GMT, Kevin Rushforth wrote: >> It seems like this is the best we can do for now. What is means is that we won't be able to build on a system with 3.8 - 3.19 and distribute a library that will use the new functionality when running on 3.20 or later. That's probably OK in this case, but is worth noting. >> >> What is important, and why the runtime check is needed (as noted above) is that we can build a production release of JavaFX on a system that has a later GTK and it will run on a system with an older GTK. It won't use the feature on those older systems, but won't crash. > > As an FYI, we use GTK 3.22 on our CI build machines so I wouldn't want to see the build-time dependency move any higher than it currently is. The suggestion was to allow building on 16.04 - so it's easier to test. But it currently does not build because of code introduced on Platform Preferences API. On the other hand, maybe it's best to fail so we make sure building requires 3.20. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1305#discussion_r1430688501 From kcr at openjdk.org Mon Dec 18 22:02:50 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Dec 2023 22:02:50 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> Message-ID: On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add compile-time checks to GdkSeat The addition of the compile-time flags looks OK. I did a build with GTK 3.22 (so it compiles the new code, does the dlsym, and does the runtime check) and verified that there are no regressions when running on an older system (Ubuntu 16.04). I then did a full test run on our headful test systems, and there is one new test failure -- it seems to be intermittent, although fails pretty consistently on our Ubuntu 22.04 and Ubuntu 20.04 test systems. I can reproduce it locally on a VM running Ubuntu 22.04, where it fails about 1/2 the time with this patch applied (it fails more often on our physical test systems). DatePickerTest > testDatePickerSceneChange FAILED java.lang.AssertionError: Timeout: Failed to receive onAction call. at org.junit.Assert.fail(Assert.java:89) at org.junit.Assert.assertTrue(Assert.java:42) at test.util.Util.waitForLatch(Util.java:400) at test.robot.javafx.scene.DatePickerTest.clickDatePickerCalendarPopup(DatePickerTest.java:90) at test.robot.javafx.scene.DatePickerTest.testDatePickerSceneChange(DatePickerTest.java:123) Not sure what to make of this. I am not aware of any problems with this test, but it's possible that your fix has exposed a latent issue either in the test or somewhere else. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1861759137 From kcr at openjdk.org Mon Dec 18 22:19:45 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Dec 2023 22:19:45 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v2] In-Reply-To: References: <_0mP3XCihDpjdPFtZKtWL0TELGWAgx6mYcQbX83XRzY=.09683bed-f6ad-4e24-90df-173fc69eac59@github.com> <0jjTW-5bIJrtf1XohxtlPDtch5_5z3nPUk81Z9zPvhw=.d4777818-ea96-4352-b27a-4994545a9bbc@github.com> <4n0N17UhDR-g0zwrBSnA8rgAbVzJ6eaEWQHsjR6GUrs=.d701d259-cbc8-4719-a298-b94812afe5b6@github.com> <_j9emR0JIqHYoEeAXzunIoBDWwI161s0C-S LBONvzPU=.d38f7d47-03de-400e-b6af-4cf54b35c378@github.com> Message-ID: On Mon, 18 Dec 2023 21:56:09 GMT, Thiago Milczarek Sayao wrote: >> As an FYI, we use GTK 3.22 on our CI build machines so I wouldn't want to see the build-time dependency move any higher than it currently is. > > The suggestion was to allow building on 16.04 - so it's easier to test. But it currently does not build because of code introduced on Platform Preferences API. On the other hand, maybe it's best to fail so we make sure building requires 3.20. The native Platform Preferences code is failing for an entirely different reason (a too-old compiler), but you raise an interesting point. If we really can't support building a distributable binary on a system with a too-old GTK library in a way that enables using a new feature like this, we might prefer to "fail fast" at build time, rather than produce a binary that doesn't support the new capability even when running on a newer system. If we decide that is a reasonable thing to do, we might want the minimum _build-time_ version of GTK to be higher than the minimum version we support at _runtime_. I think we shouldn't necessarily tie that decision to this PR. So I think the current approach in this PR: allow it to build on an older GTK without using the new functionality, is probably OK (although not ideal as evidenced by this discussion). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1305#discussion_r1430703990 From john.hendrikx at gmail.com Tue Dec 19 00:14:38 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 19 Dec 2023 01:14:38 +0100 Subject: New API: Animation/Timeline improvement In-Reply-To: References: <1991b717-755e-d44f-9537-99b583b0904a@gmail.com> Message-ID: <43d073ae-644a-67f8-8b54-995e6bf7c9b1@gmail.com> I don't think that's the correct solution, as it opens up a whole new avenue for subtle bugs, bringing GC/JVM/OS whims and settings into the mix. We want the clean-up to be easier to reason about, not harder. Even if it were a good idea, it's likely also going to be a breaking change to add weak references at this stage, without some kind of opt-in (which would then require new API, in which case we might as well go for a solution that has no need of weak references). I feel I have to keep repeating this, but there almost zero guarantees made by the JVM or Java with regards to references; they are fine for internal processes carefully designed to have no user visible side effects, but burdening the user with side effects (delayed clean-up, or early unexpected clean-up due to lack of a hard reference) without the user actually choosing to use a reference type themselves is not a good design. --John On 18/12/2023 17:18, Andy Goryachev wrote: > > Would making Timeline to use WeakReferences solve the issue without > the need for a new API? > > -andy > > *From: *openjfx-dev on behalf of John > Hendrikx > *Date: *Friday, December 15, 2023 at 21:53 > *To: *openjfx-dev > *Subject: *New API: Animation/Timeline improvement > > Hi list, > > I've noticed that Animations and Timelines are often a source of leaks, > and their clean-up is often either non-existent or incorrect.? The > reason they cause leaks easily is because a running animation or > timeline is globally referred from a singleton PrimaryTimer.? The > animation or timeline then refers to properties or event handlers which > refer to controls (which refer to parents and the entire scene). > > For example: > > - ScrollBarBehavior uses a Timeline, but neglects to clean it up.? If it > was running at the time a Scene is detached from a Window, and that > Scene is left to go out of scope, it won't because Timeline refers it; > this can happen if the behavior never receives a key released event. > > - ScrollBarBehavior has no dispose method overridden, so swapping Skins > while the animation is running will leave a Timeline active (it uses > Animation.INDEFINITE) > > - SpinnerBehavior has flawed clean up; it attaches a Scene listener and > disables its timeline when the scene changed, but the scene doesn't have > to change for it to go out of scope as a whole... Result is that if you > have a spinner timeline running, and you close the entire window (no > Scene change happens), the entire Scene will still be referred.? It also > uses an indefinite cycle count.? It also lacks a dispose method, so > swapping Skins at a bad moment can also leave a reference. > > I think these mistakes are common, and far too easy to make.? The most > common use cases for animations revolve around modifying properties on > visible controls, and although animations can be used for purposes other > than animating UI controls, this is extremely rare. So it is safe to > say that in 99% of cases you want the animation to stop once a some Node > is no longer showing. For both the mentioned buggy behaviors above, this > would be perfect.? A spinner stops spinning when no longer showing, and > a scroll bar stops scrolling when no longer showing. It is also likely > to apply for many other uses of timelines and animations. > > I therefore want to propose a new API, either on Node or Animation (or > both): > > ???? /** > ????? * Creates a new timeline which is stopped automatically when > this Node > ????? * is no longer showing. Stopping timelines is essential as they > may refer > ????? * nodes even after they are no longer used anywhere, preventing > them from > ????? * being garbage collected. > ????? */ > ???? Node.createTimeline();? // and variants with the various Timeline > constructors > > And/or: > > ???? /** > ????? * Links this Animation to the given Node, and stops the animation > ????? * automatically when the Node is no longer showing. Stopping > animations > ????? * is essential as they may refer nodes even after they are no > longer used > ????? * anywhere, preventing them from being garbage collected. > ????? */ > ???? void stopWhenHidden(Node node); > > The above API for Animation could also be provided through another > constructor, which takes a Node which will it be linked to. > > Alternatives: > > - Be a lot more diligent about cleaning up animations and timelines > (essentially maintain the status quo which has led to above bugs) > - Use this lengthy code fragment below: > > ???? Timeline timeline = new Timeline(); > > ???? someNode.sceneProperty() > ???????? .when(timeline.statusProperty().map(status -> status != > Status.STOPPED)) > ???????? .flatMap(Scene::windowProperty) > ???????? .flatMap(Window::showingProperty) > ???????? .orElse(false) > ???????? .subscribe(showing -> { > ???????????? if (!showing) timeline.stop(); > ???????? }); > > The `when` line ensures that the opposite problem (Nodes forever > referencing Timelines) doesn't occur if you are creating a new Timeline > for each use (not recommended, but nonetheless a common occurrence). > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank at webtechie.be Tue Dec 19 08:14:51 2023 From: frank at webtechie.be (Frank Delporte) Date: Tue, 19 Dec 2023 09:14:51 +0100 Subject: Streaming short pieces of text into a textarea causes a crash In-Reply-To: <18c81181706.b88e0546150919.7320243317071574633@webtechie.be> References: <18c81181706.b88e0546150919.7320243317071574633@webtechie.be> Message-ID: <18c81245644.d1c3bcab152400.4552689918614942273@webtechie.be> Hi, while experimenting with a ChatGPT-like user interface, I found a crashing JVM with different types of errors when streaming the response towards a TextArea. This is probably caused by too fast refreshes of the text as pieces of content are received within the same milliseconds: 19/12/2023 08:51:57.874 | DocsAnswerService?????????????????? | onNext?????????????? | INFO???? | Appending ' better' 19/12/2023 08:51:57.874 | DocsAnswerService?????????????????? | onNext?????????????? | INFO???? | Appending ' performance' 19/12/2023 08:51:57.875 | DocsAnswerService?????????????????? | onNext?????????????? | INFO???? | Appending ' after' 19/12/2023 08:51:57.978 | DocsAnswerService?????????????????? | onNext?????????????? | INFO???? | Appending ' the' 19/12/2023 08:51:57.979 | DocsAnswerService?????????????????? | onNext?????????????? | INFO???? | Appending ' first' 19/12/2023 08:51:57.979 | DocsAnswerService?????????????????? | onNext?????????????? | INFO???? | Appending ' and' But even when collecting this pieces of text to e.g. minimum 255 characters to reduce the number of TextArea changes, errors happen. So it's not clear how to prevent this as I can't define the threshold to be used... Dummy code causing the crash: public class SearchAction { ??? private final StringProperty answer; ??? ... ??? public StringProperty getAnswerProperty() { ??????? return answer; ??? } ??? public void appendAnswer(String token) { ??????? this.answer.set(this.answer.getValue() + token); ??? } } TextArea lastAnswer = new TextArea(); lastAnswer.textProperty().bind(searchAction.getAnswerProperty()); StreamingResponseHandler streamingResponseHandler = new StreamingResponseHandler<>() { ??????????? @Override ??????????? public void onNext(String token) { ??????????????? searchAction.appendAnswer(token); ??????????? } } Fatal Error # # A fatal error has been detected by the Java Runtime Environment: # #? SIGBUS (0xa) at pc=0x000000013f53b630, pid=13013, tid=80715 # # JRE version: OpenJDK Runtime Environment Zulu21.30+15-CA (21.0.1+12) (build 21.0.1+12-LTS) # Java VM: OpenJDK 64-Bit Server VM Zulu21.30+15-CA (21.0.1+12-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64) # Problematic frame: # j? javafx.scene.text.Text.queryAccessibleAttribute(Ljavafx/scene/AccessibleAttribute;[Ljava/lang/Object;)Ljava/lang/Object;+576 javafx.graphics at 21.0.1 # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /Users/frankdelporte/GitLab/docs-langchain4j/hs_err_pid13013.log Exception in thread "JavaFX Application Thread" java.lang.StackOverflowError: Delayed StackOverflowError due to ReservedStackAccess annotated method at javafx.graphics/com.sun.glass.ui.mac.MacAccessible.NSAccessibilityPostNotification(Native Method) at javafx.graphics/com.sun.glass.ui.mac.MacAccessible.sendNotification(MacAccessible.java:816) at javafx.graphics/javafx.scene.Node.notifyAccessibleAttributeChanged(Node.java:10004) at javafx.graphics/javafx.scene.text.Text$TextAttribute$12.invalidated(Text.java:1847) at javafx.base/javafx.beans.property.IntegerPropertyBase.markInvalid(IntegerPropertyBase.java:113) at javafx.base/javafx.beans.property.IntegerPropertyBase.set(IntegerPropertyBase.java:148) at javafx.graphics/javafx.scene.text.Text.setCaretPosition(Text.java:961) at javafx.graphics/javafx.scene.text.Text$3.invalidated(Text.java:466) at javafx.base/javafx.beans.property.StringPropertyBase.markInvalid(StringPropertyBase.java:110) at javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:145) at javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:50) at javafx.graphics/javafx.scene.text.Text.setText(Text.java:444) at javafx.controls/javafx.scene.control.skin.TextAreaSkin.lambda$new$16(TextAreaSkin.java:347) at javafx.controls/com.sun.javafx.scene.control.LambdaMultiplePropertyChangeListenerHandler.lambda$new$2(LambdaMultiplePropertyChangeListenerHandler.java:95) at javafx.base/javafx.beans.WeakInvalidationListener.invalidated(WeakInvalidationListener.java:82) at javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:360) at javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91) at javafx.controls/javafx.scene.control.TextInputControl$TextProperty.fireValueChangedEvent(TextInputControl.java:1496) at javafx.controls/javafx.scene.control.TextInputControl$TextProperty.markInvalid(TextInputControl.java:1500) at javafx.controls/javafx.scene.control.TextInputControl$TextProperty.controlContentHasChanged(TextInputControl.java:1439) at javafx.controls/javafx.scene.control.TextInputControl.lambda$new$0(TextInputControl.java:176) at javafx.base/com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:147) at javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91) at javafx.controls/javafx.scene.control.TextInputControl$ContentBase.fireValueChangedEvent(TextInputControl.java:149) at javafx.controls/javafx.scene.control.TextArea$TextAreaContent.insert(TextArea.java:214) at javafx.controls/javafx.scene.control.TextInputControl.replaceText(TextInputControl.java:1301) at javafx.controls/javafx.scene.control.TextInputControl.filterAndSet(TextInputControl.java:1266) at javafx.controls/javafx.scene.control.TextInputControl$TextProperty.doSet(TextInputControl.java:1517) at javafx.controls/javafx.scene.control.TextInputControl$TextProperty$Listener.invalidated(TextInputControl.java:1540) at javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:360) at javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91) at javafx.base/javafx.beans.property.StringPropertyBase.fireValueChangedEvent(StringPropertyBase.java:104) at javafx.base/javafx.beans.property.StringPropertyBase.markInvalid(StringPropertyBase.java:111) at javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:145) at javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:50) at com.azul.docs.langchain4j.SearchAction.appendAnswer(SearchAction.java:45) at com.azul.docs.langchain4j.DocsAnswerService$2.onNext(DocsAnswerService.java:172) at dev.langchain4j.model.openai.OpenAiStreamingChatModel.handle(OpenAiStreamingChatModel.java:152) at dev.langchain4j.model.openai.OpenAiStreamingChatModel.lambda$generate$0(OpenAiStreamingChatModel.java:133) at dev.ai4j.openai4j.StreamingRequestExecutor$2.onEvent(StreamingRequestExecutor.java:178) at okhttp3.internal.sse.RealEventSource.onEvent(RealEventSource.kt:101) at okhttp3.internal.sse.ServerSentEventReader.completeEvent(ServerSentEventReader.kt:108) at okhttp3.internal.sse.ServerSentEventReader.processNextEvent(ServerSentEventReader.kt:52) at okhttp3.internal.sse.RealEventSource.processResponse(RealEventSource.kt:75) at okhttp3.internal.sse.RealEventSource.onResponse(RealEventSource.kt:46) at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) at java.base/java.lang.Thread.run(Thread.java:1583) [93.499s][warning][os] Loading hsdis library failed # # If you would like to submit a bug report, please visit: #?? http://www.azul.com/support/ # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Process finished with exit code 134 (interrupted by signal 6:SIGABRT) Error #1 Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot read field "advances" because "this.layoutCache" is null at javafx.graphics/com.sun.javafx.text.PrismTextLayout.shape(PrismTextLayout.java:919) at javafx.graphics/com.sun.javafx.text.PrismTextLayout.layout(PrismTextLayout.java:1113) at javafx.graphics/com.sun.javafx.text.PrismTextLayout.ensureLayout(PrismTextLayout.java:230) at javafx.graphics/com.sun.javafx.text.PrismTextLayout.getBounds(PrismTextLayout.java:256) at javafx.graphics/javafx.scene.text.Text.getLogicalBounds(Text.java:432) at javafx.graphics/javafx.scene.text.Text.doComputeGeomBounds(Text.java:1186) at javafx.graphics/javafx.scene.text.Text$1.doComputeGeomBounds(Text.java:149) at javafx.graphics/com.sun.javafx.scene.shape.TextHelper.computeGeomBoundsImpl(TextHelper.java:90) at javafx.graphics/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:117) at javafx.graphics/javafx.scene.Node.updateGeomBounds(Node.java:3812) at javafx.graphics/javafx.scene.Node.getGeomBounds(Node.java:3774) at javafx.graphics/javafx.scene.Node.getLocalBounds(Node.java:3722) at javafx.graphics/javafx.scene.Node$MiscProperties$3.computeBounds(Node.java:6812) at javafx.graphics/javafx.scene.Node$LazyBoundsProperty.get(Node.java:9749) at javafx.graphics/javafx.scene.Node$LazyBoundsProperty.get(Node.java:9740) at javafx.graphics/javafx.scene.Node.getBoundsInLocal(Node.java:3402) at javafx.controls/javafx.scene.control.skin.TextAreaSkin$ContentView.layoutChildren(TextAreaSkin.java:1325) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1208) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Scene.doLayoutPass(Scene.java:594) at javafx.graphics/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2600) at javafx.graphics/com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:401) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at javafx.graphics/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:400) at javafx.graphics/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:430) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352) at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) Error #2 Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot read the array length because "this.lines" is null at javafx.graphics/com.sun.javafx.text.PrismTextLayout.layout(PrismTextLayout.java:1316) at javafx.graphics/com.sun.javafx.text.PrismTextLayout.ensureLayout(PrismTextLayout.java:230) at javafx.graphics/com.sun.javafx.text.PrismTextLayout.getBounds(PrismTextLayout.java:256) at javafx.graphics/javafx.scene.text.Text.getLogicalBounds(Text.java:432) at javafx.graphics/javafx.scene.text.Text.doComputeGeomBounds(Text.java:1186) at javafx.graphics/javafx.scene.text.Text$1.doComputeGeomBounds(Text.java:149) at javafx.graphics/com.sun.javafx.scene.shape.TextHelper.computeGeomBoundsImpl(TextHelper.java:90) at javafx.graphics/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:117) at javafx.graphics/javafx.scene.Node.updateGeomBounds(Node.java:3812) at javafx.graphics/javafx.scene.Node.getGeomBounds(Node.java:3774) at javafx.graphics/javafx.scene.Node.getLocalBounds(Node.java:3722) at javafx.graphics/javafx.scene.Node.updateTxBounds(Node.java:3876) at javafx.graphics/javafx.scene.Node.getTransformedBounds(Node.java:3668) at javafx.graphics/javafx.scene.Node.updateBounds(Node.java:776) at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) at javafx.graphics/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2615) at javafx.graphics/com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:401) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at javafx.graphics/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:400) at javafx.graphics/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:430) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352) at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) Best regards Frank Delporte Want to have coding-fun? Check my blog?https://webtechie.be/ and book "Getting started with Java on Raspberry Pi" on https://webtechie.be/books/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvos at openjdk.org Tue Dec 19 08:22:52 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 19 Dec 2023 08:22:52 GMT Subject: RFR: [WIP] 8319779: SystemMenu: memory leak due to listener never being removed [v4] In-Reply-To: References: Message-ID: On Mon, 18 Dec 2023 13:18:02 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Fix more memoryleaks due to listeners never being unregistered. Moving this to [WIP] while I'm working on automated tests. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1862311358 From jvos at openjdk.org Tue Dec 19 09:09:53 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 19 Dec 2023 09:09:53 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> Message-ID: On Mon, 18 Dec 2023 22:00:28 GMT, Kevin Rushforth wrote: > I did a build with GTK 3.22 (so it compiles the new code, does the dlsym, and does the runtime check) and verified that there are no regressions when running on an older system (Ubuntu 16.04). That sounds good. > If we decide that is a reasonable thing to do, we might want the minimum _build-time_ version of GTK to be higher than the minimum version we support at _runtime_. That makes sense. We already do this with libc. When building (using the devkit based on the OpenJDK devkit), we use later versions of certain libraries, but we make sure the binaries still work on systems with older versions of the libraries. We should clearly state the minimum runtime requirements for some libraries (rather than for distributions, as it is always possible to hack new versions of libraries into old releases) . What I really want to avoid is having 2 (or more) versions of the binaries for the same platform/arch/os combination. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1862376357 From john.hendrikx at gmail.com Tue Dec 19 09:18:44 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 19 Dec 2023 10:18:44 +0100 Subject: Streaming short pieces of text into a textarea causes a crash In-Reply-To: <18c81245644.d1c3bcab152400.4552689918614942273@webtechie.be> References: <18c81181706.b88e0546150919.7320243317071574633@webtechie.be> <18c81245644.d1c3bcab152400.4552689918614942273@webtechie.be> Message-ID: It looks like you are manipulating a property that is bound to a UI control on an external thread. Property manipulations that are tied to controls that are part of an active (visible) Scene **must** be done on the FX thread. Try: ??? StreamingResponseHandler streamingResponseHandler = new StreamingResponseHandler<>() { ? ?? ?????????? @Override ??????????????? public void onNext(String token) { ??????????????????? Platform.runLater(() -> searchAction.appendAnswer(token)); ??? ? ?? ?????? } ??? } --John On 19/12/2023 09:14, Frank Delporte wrote: > > Hi, while experimenting with a ChatGPT-like user interface, I > found a crashing JVM with different types of errors when streaming > the response towards a TextArea. This is probably caused by too > fast refreshes of the text as pieces of content are received > within the same milliseconds: > > 19/12/2023 08:51:57.874 | DocsAnswerService?????????????????? | > onNext?????????????? | INFO???? | Appending ' better' > 19/12/2023 08:51:57.874 | DocsAnswerService?????????????????? | > onNext?????????????? | INFO???? | Appending ' performance' > 19/12/2023 08:51:57.875 | DocsAnswerService?????????????????? | > onNext?????????????? | INFO???? | Appending ' after' > 19/12/2023 08:51:57.978 | DocsAnswerService?????????????????? | > onNext?????????????? | INFO???? | Appending ' the' > 19/12/2023 08:51:57.979 | DocsAnswerService?????????????????? | > onNext?????????????? | INFO???? | Appending ' first' > 19/12/2023 08:51:57.979 | DocsAnswerService?????????????????? | > onNext?????????????? | INFO???? | Appending ' and' > > But even when collecting this pieces of text to e.g. minimum 255 > characters to reduce the number of TextArea changes, errors > happen. So it's not clear how to prevent this as I can't define > the threshold to be used... > > Dummy code causing the crash: > > public class SearchAction { > ??? private final StringProperty answer; > ??? ... > ??? public StringProperty getAnswerProperty() { > ??????? return answer; > ??? } > > ??? public void appendAnswer(String token) { > ??????? this.answer.set(this.answer.getValue() + token); > ??? } > } > > TextArea lastAnswer = new TextArea(); > lastAnswer.textProperty().bind(searchAction.getAnswerProperty()); > > StreamingResponseHandler streamingResponseHandler = new > StreamingResponseHandler<>() { > ??????????? @Override > ??????????? public void onNext(String token) { > ??????????????? searchAction.appendAnswer(token); > ??????????? } > } > > *Fatal Error * > > # > # A fatal error has been detected by the Java Runtime Environment: > # > #? SIGBUS (0xa) at pc=0x000000013f53b630, pid=13013, tid=80715 > # > # JRE version: OpenJDK Runtime Environment Zulu21.30+15-CA > (21.0.1+12) (build 21.0.1+12-LTS) > # Java VM: OpenJDK 64-Bit Server VM Zulu21.30+15-CA > (21.0.1+12-LTS, mixed mode, sharing, tiered, compressed oops, > compressed class ptrs, g1 gc, bsd-aarch64) > # Problematic frame: > # j > javafx.scene.text.Text.queryAccessibleAttribute(Ljavafx/scene/AccessibleAttribute;[Ljava/lang/Object;)Ljava/lang/Object;+576 > javafx.graphics at 21.0.1 > # > # No core dump will be written. Core dumps have been disabled. To > enable core dumping, try "ulimit -c unlimited" before starting > Java again > # > # An error report file with more information is saved as: > # /Users/frankdelporte/GitLab/docs-langchain4j/hs_err_pid13013.log > Exception in thread "JavaFX Application Thread" > java.lang.StackOverflowError: Delayed StackOverflowError due to > ReservedStackAccess annotated method > at > javafx.graphics/com.sun.glass.ui.mac.MacAccessible.NSAccessibilityPostNotification(Native > Method) > at > javafx.graphics/com.sun.glass.ui.mac.MacAccessible.sendNotification(MacAccessible.java:816) > at > javafx.graphics/javafx.scene.Node.notifyAccessibleAttributeChanged(Node.java:10004) > at > javafx.graphics/javafx.scene.text.Text$TextAttribute$12.invalidated(Text.java:1847) > at > javafx.base/javafx.beans.property.IntegerPropertyBase.markInvalid(IntegerPropertyBase.java:113) > at > javafx.base/javafx.beans.property.IntegerPropertyBase.set(IntegerPropertyBase.java:148) > at > javafx.graphics/javafx.scene.text.Text.setCaretPosition(Text.java:961) > at javafx.graphics/javafx.scene.text.Text$3.invalidated(Text.java:466) > at > javafx.base/javafx.beans.property.StringPropertyBase.markInvalid(StringPropertyBase.java:110) > at > javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:145) > at > javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:50) > at javafx.graphics/javafx.scene.text.Text.setText(Text.java:444) > at > javafx.controls/javafx.scene.control.skin.TextAreaSkin.lambda$new$16(TextAreaSkin.java:347) > at > javafx.controls/com.sun.javafx.scene.control.LambdaMultiplePropertyChangeListenerHandler.lambda$new$2(LambdaMultiplePropertyChangeListenerHandler.java:95) > at > javafx.base/javafx.beans.WeakInvalidationListener.invalidated(WeakInvalidationListener.java:82) > at > javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:360) > at > javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91) > at > javafx.controls/javafx.scene.control.TextInputControl$TextProperty.fireValueChangedEvent(TextInputControl.java:1496) > at > javafx.controls/javafx.scene.control.TextInputControl$TextProperty.markInvalid(TextInputControl.java:1500) > at > javafx.controls/javafx.scene.control.TextInputControl$TextProperty.controlContentHasChanged(TextInputControl.java:1439) > at > javafx.controls/javafx.scene.control.TextInputControl.lambda$new$0(TextInputControl.java:176) > at > javafx.base/com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:147) > at > javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91) > at > javafx.controls/javafx.scene.control.TextInputControl$ContentBase.fireValueChangedEvent(TextInputControl.java:149) > at > javafx.controls/javafx.scene.control.TextArea$TextAreaContent.insert(TextArea.java:214) > at > javafx.controls/javafx.scene.control.TextInputControl.replaceText(TextInputControl.java:1301) > at > javafx.controls/javafx.scene.control.TextInputControl.filterAndSet(TextInputControl.java:1266) > at > javafx.controls/javafx.scene.control.TextInputControl$TextProperty.doSet(TextInputControl.java:1517) > at > javafx.controls/javafx.scene.control.TextInputControl$TextProperty$Listener.invalidated(TextInputControl.java:1540) > at > javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:360) > at > javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91) > at > javafx.base/javafx.beans.property.StringPropertyBase.fireValueChangedEvent(StringPropertyBase.java:104) > at > javafx.base/javafx.beans.property.StringPropertyBase.markInvalid(StringPropertyBase.java:111) > at > javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:145) > at > javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:50) > at > com.azul.docs.langchain4j.SearchAction.appendAnswer(SearchAction.java:45) > at > com.azul.docs.langchain4j.DocsAnswerService$2.onNext(DocsAnswerService.java:172) > at > dev.langchain4j.model.openai.OpenAiStreamingChatModel.handle(OpenAiStreamingChatModel.java:152) > at > dev.langchain4j.model.openai.OpenAiStreamingChatModel.lambda$generate$0(OpenAiStreamingChatModel.java:133) > at > dev.ai4j.openai4j.StreamingRequestExecutor$2.onEvent(StreamingRequestExecutor.java:178) > at > okhttp3.internal.sse.RealEventSource.onEvent(RealEventSource.kt:101) > at > okhttp3.internal.sse.ServerSentEventReader.completeEvent(ServerSentEventReader.kt:108) > at > okhttp3.internal.sse.ServerSentEventReader.processNextEvent(ServerSentEventReader.kt:52) > at > okhttp3.internal.sse.RealEventSource.processResponse(RealEventSource.kt:75) > at > okhttp3.internal.sse.RealEventSource.onResponse(RealEventSource.kt:46) > at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) > at java.base/java.lang.Thread.run(Thread.java:1583) > [93.499s][warning][os] Loading hsdis library failed > # > # If you would like to submit a bug report, please visit: > # http://www.azul.com/support/ > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > Process finished with exit code 134 (interrupted by signal 6:SIGABRT) > > *Error #1* > > Exception in thread "JavaFX Application Thread" > java.lang.NullPointerException: Cannot read field "advances" > because "this.layoutCache" is null > at > javafx.graphics/com.sun.javafx.text.PrismTextLayout.shape(PrismTextLayout.java:919) > at > javafx.graphics/com.sun.javafx.text.PrismTextLayout.layout(PrismTextLayout.java:1113) > at > javafx.graphics/com.sun.javafx.text.PrismTextLayout.ensureLayout(PrismTextLayout.java:230) > at > javafx.graphics/com.sun.javafx.text.PrismTextLayout.getBounds(PrismTextLayout.java:256) > at > javafx.graphics/javafx.scene.text.Text.getLogicalBounds(Text.java:432) > at > javafx.graphics/javafx.scene.text.Text.doComputeGeomBounds(Text.java:1186) > at > javafx.graphics/javafx.scene.text.Text$1.doComputeGeomBounds(Text.java:149) > at > javafx.graphics/com.sun.javafx.scene.shape.TextHelper.computeGeomBoundsImpl(TextHelper.java:90) > at > javafx.graphics/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:117) > at javafx.graphics/javafx.scene.Node.updateGeomBounds(Node.java:3812) > at javafx.graphics/javafx.scene.Node.getGeomBounds(Node.java:3774) > at javafx.graphics/javafx.scene.Node.getLocalBounds(Node.java:3722) > at > javafx.graphics/javafx.scene.Node$MiscProperties$3.computeBounds(Node.java:6812) > at > javafx.graphics/javafx.scene.Node$LazyBoundsProperty.get(Node.java:9749) > at > javafx.graphics/javafx.scene.Node$LazyBoundsProperty.get(Node.java:9740) > at javafx.graphics/javafx.scene.Node.getBoundsInLocal(Node.java:3402) > at > javafx.controls/javafx.scene.control.skin.TextAreaSkin$ContentView.layoutChildren(TextAreaSkin.java:1325) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1208) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics/javafx.scene.Scene.doLayoutPass(Scene.java:594) > at > javafx.graphics/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2600) > at > javafx.graphics/com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:401) > at > java.base/java.security.AccessController.doPrivileged(AccessController.java:400) > at > javafx.graphics/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:400) > at > javafx.graphics/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:430) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352) > at > javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) > > *Error #2* > > Exception in thread "JavaFX Application Thread" > java.lang.NullPointerException: Cannot read the array length > because "this.lines" is null > at > javafx.graphics/com.sun.javafx.text.PrismTextLayout.layout(PrismTextLayout.java:1316) > at > javafx.graphics/com.sun.javafx.text.PrismTextLayout.ensureLayout(PrismTextLayout.java:230) > at > javafx.graphics/com.sun.javafx.text.PrismTextLayout.getBounds(PrismTextLayout.java:256) > at > javafx.graphics/javafx.scene.text.Text.getLogicalBounds(Text.java:432) > at > javafx.graphics/javafx.scene.text.Text.doComputeGeomBounds(Text.java:1186) > at > javafx.graphics/javafx.scene.text.Text$1.doComputeGeomBounds(Text.java:149) > at > javafx.graphics/com.sun.javafx.scene.shape.TextHelper.computeGeomBoundsImpl(TextHelper.java:90) > at > javafx.graphics/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:117) > at javafx.graphics/javafx.scene.Node.updateGeomBounds(Node.java:3812) > at javafx.graphics/javafx.scene.Node.getGeomBounds(Node.java:3774) > at javafx.graphics/javafx.scene.Node.getLocalBounds(Node.java:3722) > at javafx.graphics/javafx.scene.Node.updateTxBounds(Node.java:3876) > at > javafx.graphics/javafx.scene.Node.getTransformedBounds(Node.java:3668) > at javafx.graphics/javafx.scene.Node.updateBounds(Node.java:776) > at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) > at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) > at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) > at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) > at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) > at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) > at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) > at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) > at > javafx.graphics/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2615) > at > javafx.graphics/com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:401) > at > java.base/java.security.AccessController.doPrivileged(AccessController.java:400) > at > javafx.graphics/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:400) > at > javafx.graphics/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:430) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352) > at > javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) > > Best regards > Frank Delporte > > /Want to have coding-fun? / > /Check my blog //https://webtechie.be// > /and book "Getting started with Java on > Raspberry Pi" on //https://webtechie.be/books// > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Tue Dec 19 09:28:56 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 19 Dec 2023 09:28:56 GMT Subject: RFR: [WIP] 8319779: SystemMenu: memory leak due to listener never being removed [v4] In-Reply-To: References: Message-ID: On Mon, 18 Dec 2023 13:18:02 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Fix more memoryleaks due to listeners never being unregistered. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java line 218: > 216: mb.textProperty().addListener(new WeakInvalidationListener(valueModel -> glassMenu.setTitle(parseText(mb)))); > 217: mb.disableProperty().addListener(new WeakInvalidationListener(valueModel -> glassMenu.setEnabled(!mb.isDisable()))); > 218: mb.mnemonicParsingProperty().addListener(new WeakInvalidationListener(valueModel -> glassMenu.setTitle(parseText(mb)))); Isn't this the classic mistake being made with weak listeners where you are wrapping a listener, but then are not referring it? The inner listener (which is created on the fly) is only weakly referenced, and so can be GC'd immediately. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1431137217 From jhendrikx at openjdk.org Tue Dec 19 10:02:53 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 19 Dec 2023 10:02:53 GMT Subject: RFR: [WIP] 8319779: SystemMenu: memory leak due to listener never being removed [v4] In-Reply-To: References: Message-ID: On Mon, 18 Dec 2023 13:18:02 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Fix more memoryleaks due to listeners never being unregistered. Would it be an idea to do deterministic clean-up? The JIRA tickets involved are light on details, and I don't have a Mac, so I can't test the leak (I think?), but it seems to me that you will want to remove the listeners when the menu bar isn't visible (and re-add them if it becomes visible again?). >From what I understand, these are normal JavaFX controls wrapped into adapters, and so any listeners installed through the adapter interface will end up on controls. The `GlobalMenuAdapter` seems to be tracking the `showing` property, and calls `show` / `hide` accordingly. The ticket says: > when an application loses focus, the SystemMenu is removed. When it gets focus again, the SystemMenu is "back". My question is, is there any event that can be used to trigger clean-up when this happens? Do the controls go invisible, are they no longer showing (is `hide` called?) There must be something. If there is something, then some kind of disposal can be triggered for deterministic clean-up (ie. add `dispose` method). If you can go further and distill this information into a boolean property then a pattern like this can be used: mb.textProperty() .when(showingProperty) // assumes showing property becomes false when focus is lost... .addListener(valueModel -> glassMenu.setTitle(parseText(mb))); The `showingProperty` can be fed from the hide/show event handlers to set it to the right value, perhaps combined with focus information. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1862456106 From jvos at openjdk.org Tue Dec 19 10:07:48 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 19 Dec 2023 10:07:48 GMT Subject: RFR: [WIP] 8319779: SystemMenu: memory leak due to listener never being removed [v4] In-Reply-To: References: Message-ID: On Tue, 19 Dec 2023 09:59:32 GMT, John Hendrikx wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix more memoryleaks due to listeners never being unregistered. > > Would it be an idea to do deterministic clean-up? > > The JIRA tickets involved are light on details, and I don't have a Mac, so I can't test the leak (I think?), but it seems to me that you will want to remove the listeners when the menu bar isn't visible (and re-add them if it becomes visible again?). > > From what I understand, these are normal JavaFX controls wrapped into adapters, and so any listeners installed through the adapter interface will end up on controls. The `GlobalMenuAdapter` seems to be tracking the `showing` property, and calls `show` / `hide` accordingly. > > The ticket says: > >> when an application loses focus, the SystemMenu is removed. When it gets focus again, the SystemMenu is "back". > > My question is, is there any event that can be used to trigger clean-up when this happens? Do the controls go invisible, are they no longer showing (is `hide` called?) There must be something. If there is something, then some kind of disposal can be triggered for deterministic clean-up (ie. add `dispose` method). > > If you can go further and distill this information into a boolean property then a pattern like this can be used: > > mb.textProperty() > .when(showingProperty) // assumes showing property becomes false when focus is lost... > .addListener(valueModel -> glassMenu.setTitle(parseText(mb))); > > The `showingProperty` can be fed from the hide/show event handlers to set it to the right value, perhaps combined with focus information. @hjohn You're absolutely right. It's another reason why I moved this PR to [WIP]. Instead of guessing and trying, I want to understand the deterministic path that leads to the issue with listeners being added and not removed. The one fixed in the first commit is clear, and well understood. Still, I saw uncollected listeners, with the GC root trace pointing to those other listeners (textProperty, mnemonicParsingProperty etc). Rather than trying to "fix" this with weak listeners, it is much better to find the real cause for this. In the process of finding out, I'm adding a few shim classes and unit tests so that we can clearly test for regression. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1862465132 From jvos at openjdk.org Tue Dec 19 12:26:49 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 19 Dec 2023 12:26:49 GMT Subject: RFR: [WIP] 8319779: SystemMenu: memory leak due to listener never being removed [v4] In-Reply-To: References: Message-ID: <5M-OrTlQ94IWUqnb3pgHAtK0V7c-Ev7S80ak01i_Oic=.945784e1-8a51-480e-b530-f9a55bf2b03b@github.com> On Mon, 18 Dec 2023 13:18:02 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Fix more memoryleaks due to listeners never being unregistered. As for the memory leak issue: there were several. The first commit in this PR fixed a clear memory leak, but the one that is still left is not described in the issue. It occurs because whenever the SystemMenuBar is shown after it was not shown, all MenuItems will be readded using `GlassSystemMenu.setMenu`. This will invoke `GlassSystemMenu.insertMenuItem(... MenuItemBase menuItem...)` Inside this method, platform-specific menuItems will be created, that will adapt when the `MenuItemBase` properties are changing. The annoying thing, as stated in the first comment of that method, is that we don't know if the passed `MenuItemBase` instance was previously used in this method (in which case the listeners are regisered to this instance) or not. That is why for example the `visibilityListener` is unconditionally removed (even if we don't know if it was ever added) and then added. We can do the same for the other properties (preventing the use of weak listeners), but it would be nice if we could address this case using the api introduced in the deterministic listeners management (I would very much prefer that over weak listeners). I'm not too familiar with the new API though, but it seems difficult to do this _inside_ this method, as we would still add a listener each time the method is invoked with an item that already has a listener registered? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1862664763 From jhendrikx at openjdk.org Tue Dec 19 13:27:50 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 19 Dec 2023 13:27:50 GMT Subject: RFR: [WIP] 8319779: SystemMenu: memory leak due to listener never being removed [v4] In-Reply-To: <5M-OrTlQ94IWUqnb3pgHAtK0V7c-Ev7S80ak01i_Oic=.945784e1-8a51-480e-b530-f9a55bf2b03b@github.com> References: <5M-OrTlQ94IWUqnb3pgHAtK0V7c-Ev7S80ak01i_Oic=.945784e1-8a51-480e-b530-f9a55bf2b03b@github.com> Message-ID: <24RFFbrL_x5VNCiV8ApQkbdomoIU1rUASL_jZq6N2Y8=.ffdda2b7-bcfb-4089-b0a4-291d763a88d5@github.com> On Tue, 19 Dec 2023 12:24:14 GMT, Johan Vos wrote: > As for the memory leak issue: there were several. The first commit in this PR fixed a clear memory leak, but the one that is still left is not described in the issue. It occurs because whenever the SystemMenuBar is shown after it was not shown, all MenuItems will be readded using `GlassSystemMenu.setMenu`. This will invoke `GlassSystemMenu.insertMenuItem(... MenuItemBase menuItem...)` Inside this method, platform-specific menuItems will be created, that will adapt when the `MenuItemBase` properties are changing. The annoying thing, as stated in the first comment of that method, is that we don't know if the passed `MenuItemBase` instance was previously used in this method (in which case the listeners are regisered to this instance) or not. That is why for example the `visibilityListener` is unconditionally removed (even if we don't know if it was ever added) and then added. We can do the same for the other properties (preventing the use of weak listeners), but it would be nice if we could address this case using the api introduced in the deterministic listeners management (I would very much prefer that over weak listeners). I'm not too familiar with the new API though, but it seems difficult to do this _inside_ this method, as we would still add a listener each time the method is invoked with an item that already has a listener registered? It's still a bit unclear for me. So what I write below may be off the mark. >From what I can see, `setMenus` will first remove all items, then re-add them. The `clearMenu` function seems like a logical place to remove listeners that may be present. The problem is where to keep track off the listeners. I see a few options: 1. Track the listeners in a few `Map`s in `GlassSystemMenu`, something like `Map`, with a different `Map` for each listener type (text, disabled, mnemonic, etc). Or something more elaborate with a listener holder, nested maps, etc. These maps can then iterated when `setMenus` is called to clear out ALL the listeners (or as part of `clearMenu`. 2. Similar to above but store the listener information in the properties of `Menu` 3. Using the new resource management system. Attach all listeners with a `when` condition based on a `SimpleBooleanProperty` that you **replace** each time `setMenus` is called (replacement is needed in this case as we don't know if the menus were used before or not, but it is still relatively clean). The last one works like this: Create a new non-final field: `BooleanProperty active` In `setMenus` do: if (active != null) { active.set(false); // this releases all listeners attached with `when(active)` } active = new SimpleBooleanProperty(true); // replace active with a new property, as we can't reuse it Then attach all listeners conditionally like so: mb.textProprty().when(active).addListener( ... ); The idea here is that because `active` is a different property each time `setMenus` is called, all old listeners will be removed when active goes to `false`, and will be eligible for GC because the `active` property was also replaced (and the old one, which we just set to `false`, is not referenced anywhere anymore). Illustration: ![image](https://github.com/openjdk/jfx/assets/995917/d5b67994-cab0-4743-a2d8-68127d5223af) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1862755206 From frank at webtechie.be Tue Dec 19 17:17:01 2023 From: frank at webtechie.be (Frank Delporte) Date: Tue, 19 Dec 2023 18:17:01 +0100 Subject: Streaming short pieces of text into a textarea causes a crash In-Reply-To: <18c81245644.d1c3bcab152400.4552689918614942273@webtechie.be> References: <18c81181706.b88e0546150919.7320243317071574633@webtechie.be> <18c81245644.d1c3bcab152400.4552689918614942273@webtechie.be> Message-ID: <18c8314b64e.c1e70e00230532.9135748538095378174@webtechie.be> Thanks John, quick test with this change indeed seems to solve the problem! Platform.runLater(() -> searchAction.appendAnswer(token)); I totally missed this and I didn't notice anything in the logs that was pointing in this direction. Best regards Frank Delporte Want to have coding-fun? Check my blog?https://webtechie.be/ and book "Getting started with Java on Raspberry Pi" on https://webtechie.be/books/ ---- On Tue, 19 Dec 2023 09:14:51 +0100 Frank Delporte wrote --- Hi, while experimenting with a ChatGPT-like user interface, I found a crashing JVM with different types of errors when streaming the response towards a TextArea. This is probably caused by too fast refreshes of the text as pieces of content are received within the same milliseconds: 19/12/2023 08:51:57.874 | DocsAnswerService?????????????????? | onNext?????????????? | INFO???? | Appending ' better' 19/12/2023 08:51:57.874 | DocsAnswerService?????????????????? | onNext?????????????? | INFO???? | Appending ' performance' 19/12/2023 08:51:57.875 | DocsAnswerService?????????????????? | onNext?????????????? | INFO???? | Appending ' after' 19/12/2023 08:51:57.978 | DocsAnswerService?????????????????? | onNext?????????????? | INFO???? | Appending ' the' 19/12/2023 08:51:57.979 | DocsAnswerService?????????????????? | onNext?????????????? | INFO???? | Appending ' first' 19/12/2023 08:51:57.979 | DocsAnswerService?????????????????? | onNext?????????????? | INFO???? | Appending ' and' But even when collecting this pieces of text to e.g. minimum 255 characters to reduce the number of TextArea changes, errors happen. So it's not clear how to prevent this as I can't define the threshold to be used... Dummy code causing the crash: public class SearchAction { ??? private final StringProperty answer; ??? ... ??? public StringProperty getAnswerProperty() { ??????? return answer; ??? } ??? public void appendAnswer(String token) { ??????? this.answer.set(this.answer.getValue() + token); ??? } } TextArea lastAnswer = new TextArea(); lastAnswer.textProperty().bind(searchAction.getAnswerProperty()); StreamingResponseHandler streamingResponseHandler = new StreamingResponseHandler<>() { ??????????? @Override ??????????? public void onNext(String token) { ??????????????? searchAction.appendAnswer(token); ??????????? } } Fatal Error # # A fatal error has been detected by the Java Runtime Environment: # #? SIGBUS (0xa) at pc=0x000000013f53b630, pid=13013, tid=80715 # # JRE version: OpenJDK Runtime Environment Zulu21.30+15-CA (21.0.1+12) (build 21.0.1+12-LTS) # Java VM: OpenJDK 64-Bit Server VM Zulu21.30+15-CA (21.0.1+12-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64) # Problematic frame: # j? javafx.scene.text.Text.queryAccessibleAttribute(Ljavafx/scene/AccessibleAttribute;[Ljava/lang/Object;)Ljava/lang/Object;+576 javafx.graphics at 21.0.1 # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /Users/frankdelporte/GitLab/docs-langchain4j/hs_err_pid13013.log Exception in thread "JavaFX Application Thread" java.lang.StackOverflowError: Delayed StackOverflowError due to ReservedStackAccess annotated method at javafx.graphics/com.sun.glass.ui.mac.MacAccessible.NSAccessibilityPostNotification(Native Method) at javafx.graphics/com.sun.glass.ui.mac.MacAccessible.sendNotification(MacAccessible.java:816) at javafx.graphics/javafx.scene.Node.notifyAccessibleAttributeChanged(Node.java:10004) at javafx.graphics/javafx.scene.text.Text$TextAttribute$12.invalidated(Text.java:1847) at javafx.base/javafx.beans.property.IntegerPropertyBase.markInvalid(IntegerPropertyBase.java:113) at javafx.base/javafx.beans.property.IntegerPropertyBase.set(IntegerPropertyBase.java:148) at javafx.graphics/javafx.scene.text.Text.setCaretPosition(Text.java:961) at javafx.graphics/javafx.scene.text.Text$3.invalidated(Text.java:466) at javafx.base/javafx.beans.property.StringPropertyBase.markInvalid(StringPropertyBase.java:110) at javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:145) at javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:50) at javafx.graphics/javafx.scene.text.Text.setText(Text.java:444) at javafx.controls/javafx.scene.control.skin.TextAreaSkin.lambda$new$16(TextAreaSkin.java:347) at javafx.controls/com.sun.javafx.scene.control.LambdaMultiplePropertyChangeListenerHandler.lambda$new$2(LambdaMultiplePropertyChangeListenerHandler.java:95) at javafx.base/javafx.beans.WeakInvalidationListener.invalidated(WeakInvalidationListener.java:82) at javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:360) at javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91) at javafx.controls/javafx.scene.control.TextInputControl$TextProperty.fireValueChangedEvent(TextInputControl.java:1496) at javafx.controls/javafx.scene.control.TextInputControl$TextProperty.markInvalid(TextInputControl.java:1500) at javafx.controls/javafx.scene.control.TextInputControl$TextProperty.controlContentHasChanged(TextInputControl.java:1439) at javafx.controls/javafx.scene.control.TextInputControl.lambda$new$0(TextInputControl.java:176) at javafx.base/com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:147) at javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91) at javafx.controls/javafx.scene.control.TextInputControl$ContentBase.fireValueChangedEvent(TextInputControl.java:149) at javafx.controls/javafx.scene.control.TextArea$TextAreaContent.insert(TextArea.java:214) at javafx.controls/javafx.scene.control.TextInputControl.replaceText(TextInputControl.java:1301) at javafx.controls/javafx.scene.control.TextInputControl.filterAndSet(TextInputControl.java:1266) at javafx.controls/javafx.scene.control.TextInputControl$TextProperty.doSet(TextInputControl.java:1517) at javafx.controls/javafx.scene.control.TextInputControl$TextProperty$Listener.invalidated(TextInputControl.java:1540) at javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:360) at javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91) at javafx.base/javafx.beans.property.StringPropertyBase.fireValueChangedEvent(StringPropertyBase.java:104) at javafx.base/javafx.beans.property.StringPropertyBase.markInvalid(StringPropertyBase.java:111) at javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:145) at javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:50) at com.azul.docs.langchain4j.SearchAction.appendAnswer(SearchAction.java:45) at com.azul.docs.langchain4j.DocsAnswerService$2.onNext(DocsAnswerService.java:172) at dev.langchain4j.model.openai.OpenAiStreamingChatModel.handle(OpenAiStreamingChatModel.java:152) at dev.langchain4j.model.openai.OpenAiStreamingChatModel.lambda$generate$0(OpenAiStreamingChatModel.java:133) at dev.ai4j.openai4j.StreamingRequestExecutor$2.onEvent(StreamingRequestExecutor.java:178) at okhttp3.internal.sse.RealEventSource.onEvent(RealEventSource.kt:101) at okhttp3.internal.sse.ServerSentEventReader.completeEvent(ServerSentEventReader.kt:108) at okhttp3.internal.sse.ServerSentEventReader.processNextEvent(ServerSentEventReader.kt:52) at okhttp3.internal.sse.RealEventSource.processResponse(RealEventSource.kt:75) at okhttp3.internal.sse.RealEventSource.onResponse(RealEventSource.kt:46) at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) at java.base/java.lang.Thread.run(Thread.java:1583) [93.499s][warning][os] Loading hsdis library failed # # If you would like to submit a bug report, please visit: #?? http://www.azul.com/support/ # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Process finished with exit code 134 (interrupted by signal 6:SIGABRT) Error #1 Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot read field "advances" because "this.layoutCache" is null at javafx.graphics/com.sun.javafx.text.PrismTextLayout.shape(PrismTextLayout.java:919) at javafx.graphics/com.sun.javafx.text.PrismTextLayout.layout(PrismTextLayout.java:1113) at javafx.graphics/com.sun.javafx.text.PrismTextLayout.ensureLayout(PrismTextLayout.java:230) at javafx.graphics/com.sun.javafx.text.PrismTextLayout.getBounds(PrismTextLayout.java:256) at javafx.graphics/javafx.scene.text.Text.getLogicalBounds(Text.java:432) at javafx.graphics/javafx.scene.text.Text.doComputeGeomBounds(Text.java:1186) at javafx.graphics/javafx.scene.text.Text$1.doComputeGeomBounds(Text.java:149) at javafx.graphics/com.sun.javafx.scene.shape.TextHelper.computeGeomBoundsImpl(TextHelper.java:90) at javafx.graphics/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:117) at javafx.graphics/javafx.scene.Node.updateGeomBounds(Node.java:3812) at javafx.graphics/javafx.scene.Node.getGeomBounds(Node.java:3774) at javafx.graphics/javafx.scene.Node.getLocalBounds(Node.java:3722) at javafx.graphics/javafx.scene.Node$MiscProperties$3.computeBounds(Node.java:6812) at javafx.graphics/javafx.scene.Node$LazyBoundsProperty.get(Node.java:9749) at javafx.graphics/javafx.scene.Node$LazyBoundsProperty.get(Node.java:9740) at javafx.graphics/javafx.scene.Node.getBoundsInLocal(Node.java:3402) at javafx.controls/javafx.scene.control.skin.TextAreaSkin$ContentView.layoutChildren(TextAreaSkin.java:1325) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1208) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics/javafx.scene.Scene.doLayoutPass(Scene.java:594) at javafx.graphics/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2600) at javafx.graphics/com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:401) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at javafx.graphics/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:400) at javafx.graphics/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:430) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352) at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) Error #2 Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot read the array length because "this.lines" is null at javafx.graphics/com.sun.javafx.text.PrismTextLayout.layout(PrismTextLayout.java:1316) at javafx.graphics/com.sun.javafx.text.PrismTextLayout.ensureLayout(PrismTextLayout.java:230) at javafx.graphics/com.sun.javafx.text.PrismTextLayout.getBounds(PrismTextLayout.java:256) at javafx.graphics/javafx.scene.text.Text.getLogicalBounds(Text.java:432) at javafx.graphics/javafx.scene.text.Text.doComputeGeomBounds(Text.java:1186) at javafx.graphics/javafx.scene.text.Text$1.doComputeGeomBounds(Text.java:149) at javafx.graphics/com.sun.javafx.scene.shape.TextHelper.computeGeomBoundsImpl(TextHelper.java:90) at javafx.graphics/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:117) at javafx.graphics/javafx.scene.Node.updateGeomBounds(Node.java:3812) at javafx.graphics/javafx.scene.Node.getGeomBounds(Node.java:3774) at javafx.graphics/javafx.scene.Node.getLocalBounds(Node.java:3722) at javafx.graphics/javafx.scene.Node.updateTxBounds(Node.java:3876) at javafx.graphics/javafx.scene.Node.getTransformedBounds(Node.java:3668) at javafx.graphics/javafx.scene.Node.updateBounds(Node.java:776) at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) at javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) at javafx.graphics/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2615) at javafx.graphics/com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:401) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at javafx.graphics/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:400) at javafx.graphics/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:430) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352) at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) Best regards Frank Delporte Want to have coding-fun? Check my blog?https://webtechie.be/ and book "Getting started with Java on Raspberry Pi" on https://webtechie.be/books/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Dec 19 17:56:20 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 19 Dec 2023 17:56:20 +0000 Subject: [External] : Re: New API: Animation/Timeline improvement In-Reply-To: <43d073ae-644a-67f8-8b54-995e6bf7c9b1@gmail.com> References: <1991b717-755e-d44f-9537-99b583b0904a@gmail.com> <43d073ae-644a-67f8-8b54-995e6bf7c9b1@gmail.com> Message-ID: You are right: the weak references are not suitable in this case. These cases are clearly bugs in the skins, we should log them (unless already logged); I don?t think we need new APIs. See https://bugs.openjdk.org/issues/?jql=text%20~%20%22skin%20cleanup%22%20AND%20project%20%3D%20JDK%20AND%20component%20%3D%20javafx%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20updated%20%20DESC There is an umbrella task https://bugs.openjdk.org/browse/JDK-8241364 which collects all these issues. Care to create JBS tickets? Thanks! -andy From: John Hendrikx Date: Monday, December 18, 2023 at 16:14 To: Andy Goryachev , openjfx-dev Subject: [External] : Re: New API: Animation/Timeline improvement I don't think that's the correct solution, as it opens up a whole new avenue for subtle bugs, bringing GC/JVM/OS whims and settings into the mix. We want the clean-up to be easier to reason about, not harder. Even if it were a good idea, it's likely also going to be a breaking change to add weak references at this stage, without some kind of opt-in (which would then require new API, in which case we might as well go for a solution that has no need of weak references). I feel I have to keep repeating this, but there almost zero guarantees made by the JVM or Java with regards to references; they are fine for internal processes carefully designed to have no user visible side effects, but burdening the user with side effects (delayed clean-up, or early unexpected clean-up due to lack of a hard reference) without the user actually choosing to use a reference type themselves is not a good design. --John On 18/12/2023 17:18, Andy Goryachev wrote: Would making Timeline to use WeakReferences solve the issue without the need for a new API? -andy From: openjfx-dev on behalf of John Hendrikx Date: Friday, December 15, 2023 at 21:53 To: openjfx-dev Subject: New API: Animation/Timeline improvement Hi list, I've noticed that Animations and Timelines are often a source of leaks, and their clean-up is often either non-existent or incorrect. The reason they cause leaks easily is because a running animation or timeline is globally referred from a singleton PrimaryTimer. The animation or timeline then refers to properties or event handlers which refer to controls (which refer to parents and the entire scene). For example: - ScrollBarBehavior uses a Timeline, but neglects to clean it up. If it was running at the time a Scene is detached from a Window, and that Scene is left to go out of scope, it won't because Timeline refers it; this can happen if the behavior never receives a key released event. - ScrollBarBehavior has no dispose method overridden, so swapping Skins while the animation is running will leave a Timeline active (it uses Animation.INDEFINITE) - SpinnerBehavior has flawed clean up; it attaches a Scene listener and disables its timeline when the scene changed, but the scene doesn't have to change for it to go out of scope as a whole... Result is that if you have a spinner timeline running, and you close the entire window (no Scene change happens), the entire Scene will still be referred. It also uses an indefinite cycle count. It also lacks a dispose method, so swapping Skins at a bad moment can also leave a reference. I think these mistakes are common, and far too easy to make. The most common use cases for animations revolve around modifying properties on visible controls, and although animations can be used for purposes other than animating UI controls, this is extremely rare. So it is safe to say that in 99% of cases you want the animation to stop once a some Node is no longer showing. For both the mentioned buggy behaviors above, this would be perfect. A spinner stops spinning when no longer showing, and a scroll bar stops scrolling when no longer showing. It is also likely to apply for many other uses of timelines and animations. I therefore want to propose a new API, either on Node or Animation (or both): /** * Creates a new timeline which is stopped automatically when this Node * is no longer showing. Stopping timelines is essential as they may refer * nodes even after they are no longer used anywhere, preventing them from * being garbage collected. */ Node.createTimeline(); // and variants with the various Timeline constructors And/or: /** * Links this Animation to the given Node, and stops the animation * automatically when the Node is no longer showing. Stopping animations * is essential as they may refer nodes even after they are no longer used * anywhere, preventing them from being garbage collected. */ void stopWhenHidden(Node node); The above API for Animation could also be provided through another constructor, which takes a Node which will it be linked to. Alternatives: - Be a lot more diligent about cleaning up animations and timelines (essentially maintain the status quo which has led to above bugs) - Use this lengthy code fragment below: Timeline timeline = new Timeline(); someNode.sceneProperty() .when(timeline.statusProperty().map(status -> status != Status.STOPPED)) .flatMap(Scene::windowProperty) .flatMap(Window::showingProperty) .orElse(false) .subscribe(showing -> { if (!showing) timeline.stop(); }); The `when` line ensures that the opposite problem (Nodes forever referencing Timelines) doesn't occur if you are creating a new Timeline for each use (not recommended, but nonetheless a common occurrence). --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Dec 19 18:54:53 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 19 Dec 2023 18:54:53 GMT Subject: RFR: 8321970: New table columns don't appear when using fixed cell size unless refreshing tableView [v2] In-Reply-To: References: Message-ID: On Mon, 18 Dec 2023 15:51:01 GMT, Jose Pereda wrote: >> This PR fixes an issue when a new `TableColumn` is added to a `TableView` control with fixed cell size set, where the `TableRowSkinBase` failed to add the cells for the new column. >> >> A test is included that fails before applying this PR and passes with it. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > address feedback verified the fix with the SCEE in the ticket as well as with additional manual tests in the MonkeyTester. looks good on macOS 14.1.2 ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1308#pullrequestreview-1789526626 From john.hendrikx at gmail.com Tue Dec 19 22:24:38 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 19 Dec 2023 23:24:38 +0100 Subject: Streaming short pieces of text into a textarea causes a crash In-Reply-To: <18c8314b64e.c1e70e00230532.9135748538095378174@webtechie.be> References: <18c81181706.b88e0546150919.7320243317071574633@webtechie.be> <18c81245644.d1c3bcab152400.4552689918614942273@webtechie.be> <18c8314b64e.c1e70e00230532.9135748538095378174@webtechie.be> Message-ID: <44bedeef-c7fa-022e-fac2-23770cfdc194@gmail.com> FX doesn't always warn you (as it would mean putting thread checks everywhere). The first trace however shows that the change to the TextArea did not originate from the FX thread. --John On 19/12/2023 18:17, Frank Delporte wrote: > Thanks John, quick test with this change indeed seems to solve the > problem! > Platform.runLater(() -> searchAction.appendAnswer(token)); > I totally missed this and I didn't notice anything in the logs that > was pointing in this direction. > > Best regards > Frank Delporte > > /Want to have coding-fun? / > /Check my blog //https://webtechie.be// /and > book "Getting started with Java on Raspberry Pi" on > //https://webtechie.be/books// > > > > > > ---- On Tue, 19 Dec 2023 09:14:51 +0100 *Frank Delporte > * wrote --- > > Hi, while experimenting with a ChatGPT-like user interface, I > found a crashing JVM with different types of errors when > streaming the response towards a TextArea. This is probably > caused by too fast refreshes of the text as pieces of content > are received within the same milliseconds: > > 19/12/2023 08:51:57.874 | DocsAnswerService?????????????????? > | onNext?????????????? | INFO???? | Appending ' better' > 19/12/2023 08:51:57.874 | DocsAnswerService?????????????????? > | onNext?????????????? | INFO???? | Appending ' performance' > 19/12/2023 08:51:57.875 | DocsAnswerService?????????????????? > | onNext?????????????? | INFO???? | Appending ' after' > 19/12/2023 08:51:57.978 | DocsAnswerService?????????????????? > | onNext?????????????? | INFO???? | Appending ' the' > 19/12/2023 08:51:57.979 | DocsAnswerService?????????????????? > | onNext?????????????? | INFO???? | Appending ' first' > 19/12/2023 08:51:57.979 | DocsAnswerService?????????????????? > | onNext?????????????? | INFO???? | Appending ' and' > > But even when collecting this pieces of text to e.g. minimum > 255 characters to reduce the number of TextArea changes, > errors happen. So it's not clear how to prevent this as I > can't define the threshold to be used... > > Dummy code causing the crash: > > public class SearchAction { > ??? private final StringProperty answer; > ??? ... > ??? public StringProperty getAnswerProperty() { > ??????? return answer; > ??? } > > ??? public void appendAnswer(String token) { > this.answer.set(this.answer.getValue() + token); > ??? } > } > > TextArea lastAnswer = new TextArea(); > lastAnswer.textProperty().bind(searchAction.getAnswerProperty()); > > StreamingResponseHandler streamingResponseHandler = > new StreamingResponseHandler<>() { > ??????????? @Override > ??????????? public void onNext(String token) { > searchAction.appendAnswer(token); > ??????????? } > } > > *Fatal Error * > > # > # A fatal error has been detected by the Java Runtime Environment: > # > #? SIGBUS (0xa) at pc=0x000000013f53b630, pid=13013, tid=80715 > # > # JRE version: OpenJDK Runtime Environment Zulu21.30+15-CA > (21.0.1+12) (build 21.0.1+12-LTS) > # Java VM: OpenJDK 64-Bit Server VM Zulu21.30+15-CA > (21.0.1+12-LTS, mixed mode, sharing, tiered, compressed oops, > compressed class ptrs, g1 gc, bsd-aarch64) > # Problematic frame: > # j > javafx.scene.text.Text.queryAccessibleAttribute(Ljavafx/scene/AccessibleAttribute;[Ljava/lang/Object;)Ljava/lang/Object;+576 > javafx.graphics at 21.0.1 > # > # No core dump will be written. Core dumps have been disabled. > To enable core dumping, try "ulimit -c unlimited" before > starting Java again > # > # An error report file with more information is saved as: > # /Users/frankdelporte/GitLab/docs-langchain4j/hs_err_pid13013.log > Exception in thread "JavaFX Application Thread" > java.lang.StackOverflowError: Delayed StackOverflowError due > to ReservedStackAccess annotated method > at > javafx.graphics/com.sun.glass.ui.mac.MacAccessible.NSAccessibilityPostNotification(Native > Method) > at > javafx.graphics/com.sun.glass.ui.mac.MacAccessible.sendNotification(MacAccessible.java:816) > at > javafx.graphics/javafx.scene.Node.notifyAccessibleAttributeChanged(Node.java:10004) > at > javafx.graphics/javafx.scene.text.Text$TextAttribute$12.invalidated(Text.java:1847) > at > javafx.base/javafx.beans.property.IntegerPropertyBase.markInvalid(IntegerPropertyBase.java:113) > at > javafx.base/javafx.beans.property.IntegerPropertyBase.set(IntegerPropertyBase.java:148) > at > javafx.graphics/javafx.scene.text.Text.setCaretPosition(Text.java:961) > at > javafx.graphics/javafx.scene.text.Text$3.invalidated(Text.java:466) > at > javafx.base/javafx.beans.property.StringPropertyBase.markInvalid(StringPropertyBase.java:110) > at > javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:145) > at > javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:50) > at javafx.graphics/javafx.scene.text.Text.setText(Text.java:444) > at > javafx.controls/javafx.scene.control.skin.TextAreaSkin.lambda$new$16(TextAreaSkin.java:347) > at > javafx.controls/com.sun.javafx.scene.control.LambdaMultiplePropertyChangeListenerHandler.lambda$new$2(LambdaMultiplePropertyChangeListenerHandler.java:95) > at > javafx.base/javafx.beans.WeakInvalidationListener.invalidated(WeakInvalidationListener.java:82) > at > javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:360) > at > javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91) > at > javafx.controls/javafx.scene.control.TextInputControl$TextProperty.fireValueChangedEvent(TextInputControl.java:1496) > at > javafx.controls/javafx.scene.control.TextInputControl$TextProperty.markInvalid(TextInputControl.java:1500) > at > javafx.controls/javafx.scene.control.TextInputControl$TextProperty.controlContentHasChanged(TextInputControl.java:1439) > at > javafx.controls/javafx.scene.control.TextInputControl.lambda$new$0(TextInputControl.java:176) > at > javafx.base/com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:147) > at > javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91) > at > javafx.controls/javafx.scene.control.TextInputControl$ContentBase.fireValueChangedEvent(TextInputControl.java:149) > at > javafx.controls/javafx.scene.control.TextArea$TextAreaContent.insert(TextArea.java:214) > at > javafx.controls/javafx.scene.control.TextInputControl.replaceText(TextInputControl.java:1301) > at > javafx.controls/javafx.scene.control.TextInputControl.filterAndSet(TextInputControl.java:1266) > at > javafx.controls/javafx.scene.control.TextInputControl$TextProperty.doSet(TextInputControl.java:1517) > at > javafx.controls/javafx.scene.control.TextInputControl$TextProperty$Listener.invalidated(TextInputControl.java:1540) > at > javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:360) > at > javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91) > at > javafx.base/javafx.beans.property.StringPropertyBase.fireValueChangedEvent(StringPropertyBase.java:104) > at > javafx.base/javafx.beans.property.StringPropertyBase.markInvalid(StringPropertyBase.java:111) > at > javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:145) > at > javafx.base/javafx.beans.property.StringPropertyBase.set(StringPropertyBase.java:50) > at > com.azul.docs.langchain4j.SearchAction.appendAnswer(SearchAction.java:45) > at > com.azul.docs.langchain4j.DocsAnswerService$2.onNext(DocsAnswerService.java:172) > at > dev.langchain4j.model.openai.OpenAiStreamingChatModel.handle(OpenAiStreamingChatModel.java:152) > at > dev.langchain4j.model.openai.OpenAiStreamingChatModel.lambda$generate$0(OpenAiStreamingChatModel.java:133) > at > dev.ai4j.openai4j.StreamingRequestExecutor$2.onEvent(StreamingRequestExecutor.java:178) > at > okhttp3.internal.sse.RealEventSource.onEvent(RealEventSource.kt:101) > at > okhttp3.internal.sse.ServerSentEventReader.completeEvent(ServerSentEventReader.kt:108) > at > okhttp3.internal.sse.ServerSentEventReader.processNextEvent(ServerSentEventReader.kt:52) > at > okhttp3.internal.sse.RealEventSource.processResponse(RealEventSource.kt:75) > at > okhttp3.internal.sse.RealEventSource.onResponse(RealEventSource.kt:46) > at > okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) > at java.base/java.lang.Thread.run(Thread.java:1583) > [93.499s][warning][os] Loading hsdis library failed > # > # If you would like to submit a bug report, please visit: > # http://www.azul.com/support/ > # The crash happened outside the Java Virtual Machine in > native code. > # See problematic frame for where to report the bug. > # > > Process finished with exit code 134 (interrupted by signal > 6:SIGABRT) > > *Error #1* > > Exception in thread "JavaFX Application Thread" > java.lang.NullPointerException: Cannot read field "advances" > because "this.layoutCache" is null > at > javafx.graphics/com.sun.javafx.text.PrismTextLayout.shape(PrismTextLayout.java:919) > at > javafx.graphics/com.sun.javafx.text.PrismTextLayout.layout(PrismTextLayout.java:1113) > at > javafx.graphics/com.sun.javafx.text.PrismTextLayout.ensureLayout(PrismTextLayout.java:230) > at > javafx.graphics/com.sun.javafx.text.PrismTextLayout.getBounds(PrismTextLayout.java:256) > at > javafx.graphics/javafx.scene.text.Text.getLogicalBounds(Text.java:432) > at > javafx.graphics/javafx.scene.text.Text.doComputeGeomBounds(Text.java:1186) > at > javafx.graphics/javafx.scene.text.Text$1.doComputeGeomBounds(Text.java:149) > at > javafx.graphics/com.sun.javafx.scene.shape.TextHelper.computeGeomBoundsImpl(TextHelper.java:90) > at > javafx.graphics/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:117) > at > javafx.graphics/javafx.scene.Node.updateGeomBounds(Node.java:3812) > at javafx.graphics/javafx.scene.Node.getGeomBounds(Node.java:3774) > at > javafx.graphics/javafx.scene.Node.getLocalBounds(Node.java:3722) > at > javafx.graphics/javafx.scene.Node$MiscProperties$3.computeBounds(Node.java:6812) > at > javafx.graphics/javafx.scene.Node$LazyBoundsProperty.get(Node.java:9749) > at > javafx.graphics/javafx.scene.Node$LazyBoundsProperty.get(Node.java:9740) > at > javafx.graphics/javafx.scene.Node.getBoundsInLocal(Node.java:3402) > at > javafx.controls/javafx.scene.control.skin.TextAreaSkin$ContentView.layoutChildren(TextAreaSkin.java:1325) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1208) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics/javafx.scene.Scene.doLayoutPass(Scene.java:594) > at > javafx.graphics/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2600) > at > javafx.graphics/com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:401) > at > java.base/java.security.AccessController.doPrivileged(AccessController.java:400) > at > javafx.graphics/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:400) > at > javafx.graphics/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:430) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352) > at > javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) > > *Error #2* > > Exception in thread "JavaFX Application Thread" > java.lang.NullPointerException: Cannot read the array length > because "this.lines" is null > at > javafx.graphics/com.sun.javafx.text.PrismTextLayout.layout(PrismTextLayout.java:1316) > at > javafx.graphics/com.sun.javafx.text.PrismTextLayout.ensureLayout(PrismTextLayout.java:230) > at > javafx.graphics/com.sun.javafx.text.PrismTextLayout.getBounds(PrismTextLayout.java:256) > at > javafx.graphics/javafx.scene.text.Text.getLogicalBounds(Text.java:432) > at > javafx.graphics/javafx.scene.text.Text.doComputeGeomBounds(Text.java:1186) > at > javafx.graphics/javafx.scene.text.Text$1.doComputeGeomBounds(Text.java:149) > at > javafx.graphics/com.sun.javafx.scene.shape.TextHelper.computeGeomBoundsImpl(TextHelper.java:90) > at > javafx.graphics/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:117) > at > javafx.graphics/javafx.scene.Node.updateGeomBounds(Node.java:3812) > at javafx.graphics/javafx.scene.Node.getGeomBounds(Node.java:3774) > at > javafx.graphics/javafx.scene.Node.getLocalBounds(Node.java:3722) > at > javafx.graphics/javafx.scene.Node.updateTxBounds(Node.java:3876) > at > javafx.graphics/javafx.scene.Node.getTransformedBounds(Node.java:3668) > at javafx.graphics/javafx.scene.Node.updateBounds(Node.java:776) > at > javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) > at > javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) > at > javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) > at > javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) > at > javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) > at > javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) > at > javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) > at > javafx.graphics/javafx.scene.Parent.updateBounds(Parent.java:1834) > at > javafx.graphics/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2615) > at > javafx.graphics/com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:401) > at > java.base/java.security.AccessController.doPrivileged(AccessController.java:400) > at > javafx.graphics/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:400) > at > javafx.graphics/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:430) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352) > at > javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) > > Best regards > Frank Delporte > > /Want to have coding-fun? / > /Check my blog //https://webtechie.be// > /and book "Getting started with Java on > Raspberry Pi" on //https://webtechie.be/books// > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfox at openjdk.org Wed Dec 20 17:35:58 2023 From: mfox at openjdk.org (Martin Fox) Date: Wed, 20 Dec 2023 17:35:58 GMT Subject: RFR: 8322215: [win] OS events that close the stage can cause Glass to reference freed memory Message-ID: When a Stage is closed while processing an OS message the glass peer object is deleted immediately even if it's still executing member functions. As glass unwinds the stack and executes cleanup code it's referencing freed memory. There are cases where glass generates JavaFX events back-to-back. For example, when handling the Delete key glass sends a PRESSED and TYPED event in the same routine. If the Stage is closed during the PRESSED event the code that sends the TYPED event is running inside an object that has already been deleted. When the Stage is closed glass calls the OS routine ::DestroyWindow on the HWND causing a WM_NCDESTROY message to be sent. Currently the BaseWnd object is deleted when processing this message. This PR defers the destruction until all messages have been processed. This is the same approach used in the Linux code. ------------- Commit messages: - Window context is only deleted after all messages are processed Changes: https://git.openjdk.org/jfx/pull/1309/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1309&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322215 Stats: 32 lines in 2 files changed: 30 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1309.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1309/head:pull/1309 PR: https://git.openjdk.org/jfx/pull/1309 From mfox at openjdk.org Wed Dec 20 18:52:50 2023 From: mfox at openjdk.org (Martin Fox) Date: Wed, 20 Dec 2023 18:52:50 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient In-Reply-To: References: Message-ID: On Fri, 17 Nov 2023 20:05:09 GMT, Martin Fox wrote: > On Windows a common shortcut like Ctrl+'+' could only be invoked from the main keyboard and not the numeric keypad. Toolkit.getKeyCodeForChar did not have enough context to know whether it should return a result from the main keyboard or the keypad. > > This PR alters getKeyCodeForChar to pass in the code of the key the system is trying to match against. Only the Windows platform actually uses this additional information. > > On the Mac the numeric keypad has always worked due to the odd way getKeyCodeForChar is implemented (until PR #1209 the keypad worked more reliably than the main keyboard). On Linux getKeyCodeForChar is a mess; neither the main keyboard or the numeric keypad work reliably. I have an upcoming PR which should make both work correctly. Commenting to keep the bot at bay. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1289#issuecomment-1864977054 From jpereda at openjdk.org Thu Dec 21 08:59:50 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 21 Dec 2023 08:59:50 GMT Subject: Integrated: 8321970: New table columns don't appear when using fixed cell size unless refreshing tableView In-Reply-To: References: Message-ID: On Mon, 18 Dec 2023 12:09:21 GMT, Jose Pereda wrote: > This PR fixes an issue when a new `TableColumn` is added to a `TableView` control with fixed cell size set, where the `TableRowSkinBase` failed to add the cells for the new column. > > A test is included that fails before applying this PR and passes with it. This pull request has now been integrated. Changeset: ab68b716 Author: Jose Pereda URL: https://git.openjdk.org/jfx/commit/ab68b716fbfd807918ca4a1bc096dcf40d9cfcbd Stats: 24 lines in 2 files changed: 23 ins; 0 del; 1 mod 8321970: New table columns don't appear when using fixed cell size unless refreshing tableView Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1308 From duke at openjdk.org Thu Dec 21 09:43:34 2023 From: duke at openjdk.org (satsen) Date: Thu, 21 Dec 2023 09:43:34 GMT Subject: RFR: 8301302: Platform preferences API [v44] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 7 Dec 2023 21:30:27 GMT, Michael Strau? wrote: >> The value does indeed change: >> macOS.NSColor.alternatingContentBackgroundColors = [0x1e1e1eff,0xffffff0c] >> macOS.NSColor.alternatingContentBackgroundColors = [0xffffffff,0xf4f5f5ff] >> >> >> private String f(Object x) { >> if (x == null) { >> return ""; >> } >> if (x.getClass().isArray()) { >> int sz = Array.getLength(x); >> StringBuilder sb = new StringBuilder(); >> sb.append("["); >> for (int i = 0; i < sz; i++) { >> if (i > 0) { >> sb.append(','); >> } >> sb.append(Array.get(x, i)); >> } >> sb.append("]"); >> return sb.toString(); >> } >> return x.toString(); >> } > > Thanks to all the people who were involved in developing this feature and helping to bring this across the finish line, especially @andy-goryachev-oracle @kevinrushforth @hjohn @nlisker and @jperedadnr ? Thank you for your work @mstr2. It's nice to see something new and shiny added to JavaFX. I'm looking forward for your other PRs to get integrated as well, I really like your work. Thanks. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1865947867 From fkirmaier at openjdk.org Thu Dec 21 12:38:57 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 21 Dec 2023 12:38:57 GMT Subject: RFR: 8322544 Parts of SG no longer update during rendering - overlapping - culling - dirty Message-ID: In some situations, a part of the SG is no longer rendered. I created a test program that showcases this problem. Explanation: This can happen, when a part of the SG, is covered by another Node. In this part, one node is totally covered, and the other node is visible. When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. Useful parameters for further investigations: -Djavafx.pulseLogger=true -Dprism.printrendergraph=true -Djavafx.pulseLogger.threshold=0 PR: This PR ensures the dirty flag is set to false of the tree when the culling is used. It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. It would be great to have some feedback on this solution - maybe guiding me to a better solution. I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. ------------- Commit messages: - JDK-8322544 Changes: https://git.openjdk.org/jfx/pull/1310/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1310&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322544 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1310.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1310/head:pull/1310 PR: https://git.openjdk.org/jfx/pull/1310 From fkirmaier at openjdk.org Thu Dec 21 12:57:01 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 21 Dec 2023 12:57:01 GMT Subject: RFR: 8322619 Parts of SG no longer update during rendering - overlapping - culling - dirty [v2] In-Reply-To: References: Message-ID: > In some situations, a part of the SG is no longer rendered. > I created a test program that showcases this problem. > > Explanation: > > This can happen, when a part of the SG, is covered by another Node. > In this part, one node is totally covered, and the other node is visible. > > When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. > Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. > > In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. > > In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. > > This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. > > Useful parameters for further investigations: > -Djavafx.pulseLogger=true > -Dprism.printrendergraph=true > -Djavafx.pulseLogger.threshold=0 > > PR: > This PR ensures the dirty flag is set to false of the tree when the culling is used. > It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. > It would be great to have some feedback on this solution - maybe guiding me to a better solution. > > I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. Florian Kirmaier has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: JDK-8322619 Fix for rendering bug, related to overlap - culling - dirtynodes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1310/files - new: https://git.openjdk.org/jfx/pull/1310/files/59ccdbb2..43be153f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1310&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1310&range=00-01 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1310.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1310/head:pull/1310 PR: https://git.openjdk.org/jfx/pull/1310 From fkirmaier at openjdk.org Thu Dec 21 12:57:03 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 21 Dec 2023 12:57:03 GMT Subject: RFR: 8322619 Parts of SG no longer update during rendering - overlapping - culling - dirty In-Reply-To: References: Message-ID: On Thu, 21 Dec 2023 12:33:52 GMT, Florian Kirmaier wrote: > In some situations, a part of the SG is no longer rendered. > I created a test program that showcases this problem. > > Explanation: > > This can happen, when a part of the SG, is covered by another Node. > In this part, one node is totally covered, and the other node is visible. > > When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. > Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. > > In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. > > In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. > > This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. > > Useful parameters for further investigations: > -Djavafx.pulseLogger=true > -Dprism.printrendergraph=true > -Djavafx.pulseLogger.threshold=0 > > PR: > This PR ensures the dirty flag is set to false of the tree when the culling is used. > It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. > It would be great to have some feedback on this solution - maybe guiding me to a better solution. > > I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. *Fixed wrong ticket-number in title and commit* ------------- PR Comment: https://git.openjdk.org/jfx/pull/1310#issuecomment-1866196438 From kcr at openjdk.org Thu Dec 21 15:15:51 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 21 Dec 2023 15:15:51 GMT Subject: RFR: 8322619 Parts of SG no longer update during rendering - overlapping - culling - dirty [v2] In-Reply-To: References: Message-ID: <0bY6k0RqAvLJEegdCd0lCXSbga2OuMjSpIpm_07LY8g=.e5b94ade-3361-497e-aafa-e65e72b39a28@github.com> On Thu, 21 Dec 2023 12:57:01 GMT, Florian Kirmaier wrote: >> In some situations, a part of the SG is no longer rendered. >> I created a test program that showcases this problem. >> >> Explanation: >> >> This can happen, when a part of the SG, is covered by another Node. >> In this part, one node is totally covered, and the other node is visible. >> >> When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. >> Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. >> >> In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. >> >> In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. >> >> This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. >> >> Useful parameters for further investigations: >> -Djavafx.pulseLogger=true >> -Dprism.printrendergraph=true >> -Djavafx.pulseLogger.threshold=0 >> >> PR: >> This PR ensures the dirty flag is set to false of the tree when the culling is used. >> It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. >> It would be great to have some feedback on this solution - maybe guiding me to a better solution. >> >> I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. > > Florian Kirmaier has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8322619 Fix for rendering bug, related to overlap - culling - dirtynodes I'd like to see an automated (probably robot-based) test, if it is feasible. This will need careful review. Reviewers: @arapte @lukostyra .idea/jpa-buddy.xml line 1: > 1: Please revert the addition of this file. modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java line 2006: > 2004: // If no culling bits are set for this region, this group > 2005: // does not intersect (nor is covered by) the region > 2006: clearDirtyTree(); We'll need to look at this closely to ensure that there are no functional regressions, and that the performance impact is minimal. ------------- PR Review: https://git.openjdk.org/jfx/pull/1310#pullrequestreview-1793117605 PR Review Comment: https://git.openjdk.org/jfx/pull/1310#discussion_r1434166637 PR Review Comment: https://git.openjdk.org/jfx/pull/1310#discussion_r1434169228 From kcr at openjdk.org Thu Dec 21 15:17:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 21 Dec 2023 15:17:49 GMT Subject: RFR: 8301219: JavaFX crash when closing with the escape key [v3] In-Reply-To: References: Message-ID: <8Y8Pa9gqjHt1z8MCzAxRTIbWubtwQDqktdQdgbyAPG8=.0b5d53c6-f8cb-4121-8e12-c2be4b7474cd@github.com> On Mon, 18 Dec 2023 19:15:03 GMT, Martin Fox wrote: >> While processing a key down event the Glass GTK code sends out PRESSED and TYPED KeyEvents back to back. If the stage is closed during the PRESSED event the code will end up referencing freed memory while sending out the TYPED event. This can lead to intermittent crashes. >> >> In GlassApplication.cpp the EventCounterHelper object ensures the WindowContext isn't deleted while processing an event. Currently the helper object is being created *after* IME handling instead of before. If the IME is enabled it's possible for the WindowContext to be deleted in the middle of executing a number of keyboard-related events. >> >> The fix is simple; instantiate the EventCounterHelper object earlier. There isn't always a WindowContext so I tweaked the EventCounterHelper to do nothing if the context is null. >> >> To make the crash more reproducible I altered the WindowContext such that when it's deleted the freed memory is filled with 0xCC. This made the crash more reproducible and allowed me to test the fix. I did the same with GlassView since that's the only other Glass GTK class that's instantiated with `new` and discarded with `delete`. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Consistent use of FILL in mem debug code. @tsayao Would you like to review this? If not, can someone else be the second reviewer? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1307#issuecomment-1866462458 From fkirmaier at openjdk.org Thu Dec 21 15:48:47 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 21 Dec 2023 15:48:47 GMT Subject: RFR: 8322619 Parts of SG no longer update during rendering - overlapping - culling - dirty [v2] In-Reply-To: References: Message-ID: On Thu, 21 Dec 2023 12:57:01 GMT, Florian Kirmaier wrote: >> In some situations, a part of the SG is no longer rendered. >> I created a test program that showcases this problem. >> >> Explanation: >> >> This can happen, when a part of the SG, is covered by another Node. >> In this part, one node is totally covered, and the other node is visible. >> >> When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. >> Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. >> >> In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. >> >> In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. >> >> This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. >> >> Useful parameters for further investigations: >> -Djavafx.pulseLogger=true >> -Dprism.printrendergraph=true >> -Djavafx.pulseLogger.threshold=0 >> >> PR: >> This PR ensures the dirty flag is set to false of the tree when the culling is used. >> It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. >> It would be great to have some feedback on this solution - maybe guiding me to a better solution. >> >> I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. > > Florian Kirmaier has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8322619 Fix for rendering bug, related to overlap - culling - dirtynodes If someone who understands the rendering could provide some feedback on what is happening - than I can probably make a better fix, and write a reasonable unit-test for this bug. The current fix is a bit suboptimal - because the call to clean-dirty is O(n) and might be called n time - leading to O(n^2) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1310#issuecomment-1866529908 From jhendrikx at openjdk.org Fri Dec 22 08:36:50 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 22 Dec 2023 08:36:50 GMT Subject: RFR: 8322619 Parts of SG no longer update during rendering - overlapping - culling - dirty [v2] In-Reply-To: References: Message-ID: On Thu, 21 Dec 2023 12:57:01 GMT, Florian Kirmaier wrote: >> In some situations, a part of the SG is no longer rendered. >> I created a test program that showcases this problem. >> >> Explanation: >> >> This can happen, when a part of the SG, is covered by another Node. >> In this part, one node is totally covered, and the other node is visible. >> >> When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. >> Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. >> >> In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. >> >> In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. >> >> This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. >> >> Useful parameters for further investigations: >> -Djavafx.pulseLogger=true >> -Dprism.printrendergraph=true >> -Djavafx.pulseLogger.threshold=0 >> >> PR: >> This PR ensures the dirty flag is set to false of the tree when the culling is used. >> It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. >> It would be great to have some feedback on this solution - maybe guiding me to a better solution. >> >> I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. > > Florian Kirmaier has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8322619 Fix for rendering bug, related to overlap - culling - dirtynodes The fully covered node which was dirty is now marked clean in the PR when it is culled. Now that it is clean, what happens when it is uncovered (being careful not to change it in any other way)? Does it get rendered correctly, or does it miss the last change made to it while it was fully covered? If that works correctly still, then I think this is the right fix. Culling the node is (IMHO) the same as rendering it (there is nothing to render) so it should be clean after being culled. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1310#issuecomment-1867391189 From duke at openjdk.org Fri Dec 22 10:22:52 2023 From: duke at openjdk.org (Daniel) Date: Fri, 22 Dec 2023 10:22:52 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) Hi John, I've been working on moving our project from Java 8 to Java 17 and JavaFX 21 for the past month. But I can't seem to fix a bug that keeps showing up, even after running the applications for over 10 days on JavaFX version 21.0.1. Now, I'm having trouble compiling javafx-graphics for Windows. Any ideas on how to figure out what's causing the problem? best regards, Daniel ![image](https://github.com/openjdk/jfx/assets/5691507/7f932d67-9a5d-448e-a87c-519ddeb42767) 2023-12-15 11:00:37,026 ERROR [JavaFX Application Thread] c.m.a.e.AdviseUncaughtExceptionHandler [?:?] AdviseUncaughtExceptionHandler uncaughtException detects NullPointerException 2023-12-15 11:00:37,026 ERROR [JavaFX Application Thread] c.m.a.e.AdviseUncaughtExceptionHandler [?:?] NullPointerException => java.lang.NullPointerException: Cannot invoke "javafx.scene.Node.getScene()" because "" is null at javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2483) at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2630) at com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:401) at java.base/java.security.AccessController.doPrivileged(AccessController.java:399) at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:400) at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:430) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572) at com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:185) at java.base/java.lang.Thread.run(Thread.java:840) 2023-12-15 11:00:37,027 ERROR [JavaFX Application Thread] c.m.a.e.AdviseUncaughtExceptionHandler [?:?] Exception java.lang.NullPointerException: Cannot invoke "javafx.scene.Node.getScene()" because "" is null at javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2483) at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2630) at com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:401) at java.base/java.security.AccessController.doPrivileged(AccessController.java:399) at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:400) at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:430) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572) at com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:185) at java.base/java.lang.Thread.run(Thread.java:840) 2023-12-15 11:00:37,029 ERROR [JavaFX Application Thread] c.m.a.e.AdviseUncaughtExceptionHandler [?:?] B??HHMM, get more informations => java.lang.NullPointerException: Cannot invoke "javafx.scene.Node.getScene()" because "" is null at javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2483) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1123#issuecomment-1867506290 From jhendrikx at openjdk.org Fri Dec 22 10:40:51 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 22 Dec 2023 10:40:51 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) If you are not using modules, you don't need to compile javafx.graphics to attempt to analyze the problem. You can include a copy of `Scene` with your sources (making sure that it is in the original package `javafx.scene`) to debug this further. If you can reproduce this problem in a small program that you can share, we can try and find out why there is a NPE there -- if only a single thread is using the `dirtyNodes` array, I don't think there can be a `null` in there, but perhaps there is a mistake in the code. As noted before, a possible cause of this problem is accessing FX components that are currently part of the Scene graph on the wrong thread. This is not allowed, and such accesses must be wrapped in `Platform::runLater`. I realize that in a large application it might be hard to find what is doing this, but if you have multiple threads, then inspect if any thread is accessing FX components (like `Node`s, `Timeline`s, etc) directly. Not all such calls will inform you of problems, so assuming that a call is allowed because you didn't get an exception is incorrect. edit: feel free to contact me more directly (gmail john.hendrikx) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1123#issuecomment-1867524649 From fkirmaier at openjdk.org Fri Dec 22 12:56:50 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Fri, 22 Dec 2023 12:56:50 GMT Subject: RFR: 8322619 Parts of SG no longer update during rendering - overlapping - culling - dirty [v2] In-Reply-To: References: Message-ID: On Thu, 21 Dec 2023 12:57:01 GMT, Florian Kirmaier wrote: >> In some situations, a part of the SG is no longer rendered. >> I created a test program that showcases this problem. >> >> Explanation: >> >> This can happen, when a part of the SG, is covered by another Node. >> In this part, one node is totally covered, and the other node is visible. >> >> When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. >> Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. >> >> In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. >> >> In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. >> >> This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. >> >> Useful parameters for further investigations: >> -Djavafx.pulseLogger=true >> -Dprism.printrendergraph=true >> -Djavafx.pulseLogger.threshold=0 >> >> PR: >> This PR ensures the dirty flag is set to false of the tree when the culling is used. >> It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. >> It would be great to have some feedback on this solution - maybe guiding me to a better solution. >> >> I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. > > Florian Kirmaier has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8322619 Fix for rendering bug, related to overlap - culling - dirtynodes It is worth noting that the idea of cleaning the dirty tree, for the culled node, is also done at line `NGNode:1414`, but for some reason, it doesn't catch the case from this bug. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1310#issuecomment-1867654647 From duke at openjdk.org Fri Dec 22 19:39:50 2023 From: duke at openjdk.org (duke) Date: Fri, 22 Dec 2023 19:39:50 GMT Subject: Withdrawn: 8308644: [Linux] Missing mappings for dead keys + Alt Gr In-Reply-To: References: Message-ID: On Mon, 22 May 2023 00:19:45 GMT, Thiago Milczarek Sayao wrote: > This PR adds missing key mappings for dead keys and fixes "Alt Gr" for some systems. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1143 From mfox at openjdk.org Fri Dec 22 20:53:56 2023 From: mfox at openjdk.org (Martin Fox) Date: Fri, 22 Dec 2023 20:53:56 GMT Subject: RFR: 8308644: [Linux] Missing mappings for dead keys + Alt Gr [v5] In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 11:45:30 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 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/97b01884...aad021a6 My apologies, I have been reviewing this but didn't get around to writing up my comments. Currently JavaFX assumes that AltGr will be reported as Alt_R. On ISO keyboards (including U.K. English) AltGr is reported as ISO_Level3_Shift. On these keyboards ISO_Level3_Shift is also the only keyval that works if we want to target AltGr using a Robot. Just adding a second entry to the table isn't sufficient to fix that, currently the Robot will only attempt one code and at the moment it's Alt_R. I'll add AltGr to the KeyboardTest app, make sure ISO_Level3_Shift is in the table, and update the Robot code as part of fixing [JDK-8278924](https://bugs.openjdk.org/browse/JDK-8278924). I do want the dead key changes in at some point. There's no reason for us to misidentify keys when the changes are this easy and adding them to the table will enable testing of dead key handling using a Robot. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1143#issuecomment-1868061121 From nlisker at gmail.com Sat Dec 23 19:24:10 2023 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 23 Dec 2023 21:24:10 +0200 Subject: Converting a Color object to its string representation In-Reply-To: <036901da3029$32e98c90$98bca5b0$@leshem.life> References: <079901da2c77$85199e70$8f4cdb50$@leshem.life> <1BB9FE54-1C72-4B7A-9F45-E55C02DDAA54@gmail.com> <006501da2d57$fd6350c0$f829f240$@leshem.life> <02d77b6d-8646-446f-9cee-126fd3434a8c@oracle.com> <036901da3029$32e98c90$98bca5b0$@leshem.life> Message-ID: I recently came across a place where I needed this conversion. This is what I did: String fullName = color.toString(); String cssName = "#" + fullName.substring(2, fullName.length() - 2); Is this what you want to avoid writing? (Ignoring that the javadox of toString() says "The content and format of the returned string might vary between implementations.") On Sat, Dec 16, 2023 at 4:07?PM Eran Leshem wrote: > Thanks. > > > > The #rrggbbaa format isn?t documented on > https://openjfx.io/javadoc/21/javafx.graphics/javafx/scene/doc-files/cssref.html#typecolor > for some reason, so I missed it. Can I contribute a fix to the doc? > > > > What?s the process for approving option 1? > > Eran > > > > *From:* openjfx-dev [mailto:openjfx-dev-retn at openjdk.org] *On Behalf Of *Kevin > Rushforth > *Sent:* Wednesday, December 13, 2023 2:46 PM > *To:* openjfx-dev at openjdk.org > *Subject:* Re: Converting a Color object to its string representation > > > > Or the third option: > > 3. Do nothing > > I would go for option 1 or 3. I do not recommend option 2. > > I see some value in a minimal API (option 1), returning a fixed format, > perhaps: > > if alpha == 1 { "#rrggbb" } else { "#rrggbbaa" } > > -- Kevin > > On 12/12/2023 4:04 PM, Eran Leshem wrote: > > I can see two options: > > 1. Minimal, just in order to satisfy the style APIs need ? > supporting a single format. I would go with non-% rgba, since it covers all > dimensions in the most straightforward way. > > 2. Complete ? supporting all formats accepted by Color.web(), > either via multiple methods or via an enum parameter > > > > Eran > > > > *From:* openjfx-dev [mailto:openjfx-dev-retn at openjdk.org > ] *On Behalf Of *Andy Goryachev > *Sent:* Tuesday, December 12, 2023 6:08 PM > *To:* Scott Palmer; openjfx-dev at openjdk.org > *Subject:* Re: Converting a Color object to its string representation > > > > I also think that the platform will benefit from adding this symmetrical > API. > > > > It is less clear how that new API should deal with all the multiple > variants of the web format (#rgb, #rrggbb, rgb, rgba, 0x*, ...). > > > > -andy > > > > > > > > *From: *openjfx-dev > on behalf of Scott Palmer > > *Date: *Monday, December 11, 2023 at 17:12 > *To: *openjfx-dev at openjdk.org > > *Subject: *Re: Converting a Color object to its string representation > > I agree. I was going to write pretty much this exact email, but you beat > me to it. > > I was implementing some user-configurable colour customizations in an > application and needed to do it with style sheets, along with something > that reads colours along the lines of what the new platform preferences API > does. > > I make a base64 data URL from a dynamically generated style sheet to avoid > writing temp CSS files to style the app. > > I also needed to do this to work around the style sheet having higher > priority than programmatically set colours as per my misunderstanding in > https://bugs.openjdk.org/browse/JDK-8317434 > > So I see value in having Color implement something like this. > > > > Scott > > > > On Dec 11, 2023, at 4:19?PM, Eran Leshem > wrote: > > ?Thank you for your responses. > > Given that the framework requires colors in string format in its style > APIs, I think it should provide some way to convert colors to strings as > expected by these APIs. Otherwise, clients are forced to implement this > bridging logic on their own, due to a framework gap. > > And given that Color already parses these string representations, I think > it makes sense for it to provide the inverse conversion. > > Eran > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-retn at openjdk.org > ] On Behalf Of John Hendrikx > Sent: Saturday, December 09, 2023 11:35 PM > To: openjfx-dev at openjdk.org > Subject: Re: Converting a Color object to its string representation > > I think this is too niche to have Color provide. > > Just make a utility method for whatever format you desire, instead of > making Color responsible for half a dozen ways of formatting colors, and > then probably still missing some format that someone needs. > > Ticket should be closed as won't fix. > > --John > > On 09/12/2023 22:06, Michael Strau? wrote: > > I obviously meant to write withPrefix("#"), not withDelimiter("#")... > > > > On Sat, Dec 9, 2023 at 9:57?PM Michael Strau? > wrote: > > How would HexFormat work with Color, other than using an extremely > > unwieldy syntax? > > > > String formatted = HexFormat.of() > > .withDelimiter("#") > > .formatHex(new byte[] { > > (byte)(color.getRed() * 255.0f), > > (byte)(color.getGreen() * 255.0f), > > (byte)(color.getBlue() * 255.0f), > > (byte)(color.getOpacity() * 255.0f) > > }); > > > > > > > > On Sat, Dec 9, 2023 at 9:40?PM David Alayachew > wrote: > > Apologies - java.util.HexFormat > > > > That's what I get for firing from the hip, then looking afterwards. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsayao at openjdk.org Sat Dec 23 20:16:52 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 23 Dec 2023 20:16:52 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> Message-ID: On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add compile-time checks to GdkSeat I did compile (updating gcc) and test on Ubuntu 16.04 and Ubuntu 23.10 with Xorg and Wayland. All OK. Code LGTM. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1868362953 From eran at leshem.life Sat Dec 23 23:38:07 2023 From: eran at leshem.life (Eran Leshem) Date: Sun, 24 Dec 2023 01:38:07 +0200 Subject: Converting a Color object to its string representation In-Reply-To: References: <079901da2c77$85199e70$8f4cdb50$@leshem.life> <1BB9FE54-1C72-4B7A-9F45-E55C02DDAA54@gmail.com> <006501da2d57$fd6350c0$f829f240$@leshem.life> <02d77b6d-8646-446f-9cee-126fd3434a8c@oracle.com> <036901da3029$32e98c90$98bca5b0$@leshem.life> Message-ID: <001e01da35f9$15c01690$414043b0$@leshem.life> Yes, exactly what I would like every client to avoid writing. Eran From: Nir Lisker [mailto:nlisker at gmail.com] Sent: Saturday, December 23, 2023 9:24 PM To: Eran Leshem Cc: Kevin Rushforth; openjfx-dev at openjdk.org Subject: Re: Converting a Color object to its string representation I recently came across a place where I needed this conversion. This is what I did: String fullName = color.toString(); String cssName = "#" + fullName.substring(2, fullName.length() - 2); Is this what you want to avoid writing? (Ignoring that the javadox of toString() says "The content and format of the returned string might vary between implementations.") On Sat, Dec 16, 2023 at 4:07?PM Eran Leshem wrote: Thanks. The #rrggbbaa format isn?t documented on https://openjfx.io/javadoc/21/javafx.graphics/javafx/scene/doc-files/cssref.html#typecolor for some reason, so I missed it. Can I contribute a fix to the doc? What?s the process for approving option 1? Eran From: openjfx-dev [mailto:openjfx-dev-retn at openjdk.org] On Behalf Of Kevin Rushforth Sent: Wednesday, December 13, 2023 2:46 PM To: openjfx-dev at openjdk.org Subject: Re: Converting a Color object to its string representation Or the third option: 3. Do nothing I would go for option 1 or 3. I do not recommend option 2. I see some value in a minimal API (option 1), returning a fixed format, perhaps: if alpha == 1 { "#rrggbb" } else { "#rrggbbaa" } -- Kevin On 12/12/2023 4:04 PM, Eran Leshem wrote: I can see two options: 1. Minimal, just in order to satisfy the style APIs need ? supporting a single format. I would go with non-% rgba, since it covers all dimensions in the most straightforward way. 2. Complete ? supporting all formats accepted by Color.web(), either via multiple methods or via an enum parameter Eran From: openjfx-dev [mailto:openjfx-dev-retn at openjdk.org] On Behalf Of Andy Goryachev Sent: Tuesday, December 12, 2023 6:08 PM To: Scott Palmer; openjfx-dev at openjdk.org Subject: Re: Converting a Color object to its string representation I also think that the platform will benefit from adding this symmetrical API. It is less clear how that new API should deal with all the multiple variants of the web format (#rgb, #rrggbb, rgb, rgba, 0x*, ...). -andy From: openjfx-dev on behalf of Scott Palmer Date: Monday, December 11, 2023 at 17:12 To: openjfx-dev at openjdk.org Subject: Re: Converting a Color object to its string representation I agree. I was going to write pretty much this exact email, but you beat me to it. I was implementing some user-configurable colour customizations in an application and needed to do it with style sheets, along with something that reads colours along the lines of what the new platform preferences API does. I make a base64 data URL from a dynamically generated style sheet to avoid writing temp CSS files to style the app. I also needed to do this to work around the style sheet having higher priority than programmatically set colours as per my misunderstanding in https://bugs.openjdk.org/browse/JDK-8317434 So I see value in having Color implement something like this. Scott On Dec 11, 2023, at 4:19?PM, Eran Leshem wrote: ?Thank you for your responses. Given that the framework requires colors in string format in its style APIs, I think it should provide some way to convert colors to strings as expected by these APIs. Otherwise, clients are forced to implement this bridging logic on their own, due to a framework gap. And given that Color already parses these string representations, I think it makes sense for it to provide the inverse conversion. Eran -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-retn at openjdk.org] On Behalf Of John Hendrikx Sent: Saturday, December 09, 2023 11:35 PM To: openjfx-dev at openjdk.org Subject: Re: Converting a Color object to its string representation I think this is too niche to have Color provide. Just make a utility method for whatever format you desire, instead of making Color responsible for half a dozen ways of formatting colors, and then probably still missing some format that someone needs. Ticket should be closed as won't fix. --John On 09/12/2023 22:06, Michael Strau? wrote: I obviously meant to write withPrefix("#"), not withDelimiter("#")... On Sat, Dec 9, 2023 at 9:57?PM Michael Strau? wrote: How would HexFormat work with Color, other than using an extremely unwieldy syntax? String formatted = HexFormat.of() .withDelimiter("#") .formatHex(new byte[] { (byte)(color.getRed() * 255.0f), (byte)(color.getGreen() * 255.0f), (byte)(color.getBlue() * 255.0f), (byte)(color.getOpacity() * 255.0f) }); On Sat, Dec 9, 2023 at 9:40?PM David Alayachew wrote: Apologies - java.util.HexFormat That's what I get for firing from the hip, then looking afterwards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsayao at openjdk.org Sun Dec 24 01:41:47 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 24 Dec 2023 01:41:47 GMT Subject: RFR: 8301219: JavaFX crash when closing with the escape key [v3] In-Reply-To: References: Message-ID: On Mon, 18 Dec 2023 19:15:03 GMT, Martin Fox wrote: >> While processing a key down event the Glass GTK code sends out PRESSED and TYPED KeyEvents back to back. If the stage is closed during the PRESSED event the code will end up referencing freed memory while sending out the TYPED event. This can lead to intermittent crashes. >> >> In GlassApplication.cpp the EventCounterHelper object ensures the WindowContext isn't deleted while processing an event. Currently the helper object is being created *after* IME handling instead of before. If the IME is enabled it's possible for the WindowContext to be deleted in the middle of executing a number of keyboard-related events. >> >> The fix is simple; instantiate the EventCounterHelper object earlier. There isn't always a WindowContext so I tweaked the EventCounterHelper to do nothing if the context is null. >> >> To make the crash more reproducible I altered the WindowContext such that when it's deleted the freed memory is filled with 0xCC. This made the crash more reproducible and allowed me to test the fix. I did the same with GlassView since that's the only other Glass GTK class that's instantiated with `new` and discarded with `delete`. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Consistent use of FILL in mem debug code. It's always failing on my machine - I'll check why. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1307#issuecomment-1868408809 From tsayao at openjdk.org Sun Dec 24 14:20:49 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 24 Dec 2023 14:20:49 GMT Subject: RFR: 8301219: JavaFX crash when closing with the escape key [v3] In-Reply-To: References: Message-ID: On Mon, 18 Dec 2023 19:15:03 GMT, Martin Fox wrote: >> While processing a key down event the Glass GTK code sends out PRESSED and TYPED KeyEvents back to back. If the stage is closed during the PRESSED event the code will end up referencing freed memory while sending out the TYPED event. This can lead to intermittent crashes. >> >> In GlassApplication.cpp the EventCounterHelper object ensures the WindowContext isn't deleted while processing an event. Currently the helper object is being created *after* IME handling instead of before. If the IME is enabled it's possible for the WindowContext to be deleted in the middle of executing a number of keyboard-related events. >> >> The fix is simple; instantiate the EventCounterHelper object earlier. There isn't always a WindowContext so I tweaked the EventCounterHelper to do nothing if the context is null. >> >> To make the crash more reproducible I altered the WindowContext such that when it's deleted the freed memory is filled with 0xCC. This made the crash more reproducible and allowed me to test the fix. I did the same with GlassView since that's the only other Glass GTK class that's instantiated with `new` and discarded with `delete`. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Consistent use of FILL in mem debug code. The change looks correct to me - the change makes sense, but I can't reproduce the crash on my systems. I can confirm that it's reaching the `delete ctx` correctly. I didn't know about the `0xCC` debug trick. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1307#issuecomment-1868527442 From tsayao at openjdk.org Sun Dec 24 14:22:57 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 24 Dec 2023 14:22:57 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 16:41:24 GMT, Martin Fox wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > I ran into similar failures when I added a method to a core class but did not add it to the Stub version of the same class. In my case I added a call to Stage.java but didn't add it to SubStage.java. > > I'll be away from my computer for about a week and will take a closer look at this when I get back. I did notice that when I press a dead key the caret ends up at the beginning of the preview string when it should be at the end. There's also an issue with the way keys on the numeric keypad are being encoded. The fix is minor (I think) and I'll send details when I get back. Beyond that I don't understand the IME machinery so here's hoping that someone who does can spare some cycles to review this. There's a bug when closing the window with a key, as pointed by @beldenfox on #1307. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1868527856 From tsayao at openjdk.org Sun Dec 24 14:23:49 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 24 Dec 2023 14:23:49 GMT Subject: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3] In-Reply-To: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> References: <8Txn3X6Bav4uuyv4N5AhHYIMTTuq-w72szfaI7VsWI4=.be541f7d-fec2-403c-a0de-d0bf40d3aed7@github.com> Message-ID: On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add compile-time checks to GdkSeat Looks good. ------------- Marked as reviewed by tsayao (Committer). PR Review: https://git.openjdk.org/jfx/pull/1305#pullrequestreview-1795582193 From tsayao at openjdk.org Sun Dec 24 14:24:50 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 24 Dec 2023 14:24:50 GMT Subject: RFR: 8301219: JavaFX crash when closing with the escape key [v3] In-Reply-To: References: Message-ID: On Mon, 18 Dec 2023 19:15:03 GMT, Martin Fox wrote: >> While processing a key down event the Glass GTK code sends out PRESSED and TYPED KeyEvents back to back. If the stage is closed during the PRESSED event the code will end up referencing freed memory while sending out the TYPED event. This can lead to intermittent crashes. >> >> In GlassApplication.cpp the EventCounterHelper object ensures the WindowContext isn't deleted while processing an event. Currently the helper object is being created *after* IME handling instead of before. If the IME is enabled it's possible for the WindowContext to be deleted in the middle of executing a number of keyboard-related events. >> >> The fix is simple; instantiate the EventCounterHelper object earlier. There isn't always a WindowContext so I tweaked the EventCounterHelper to do nothing if the context is null. >> >> To make the crash more reproducible I altered the WindowContext such that when it's deleted the freed memory is filled with 0xCC. This made the crash more reproducible and allowed me to test the fix. I did the same with GlassView since that's the only other Glass GTK class that's instantiated with `new` and discarded with `delete`. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Consistent use of FILL in mem debug code. Looks good. ------------- Marked as reviewed by tsayao (Committer). PR Review: https://git.openjdk.org/jfx/pull/1307#pullrequestreview-1795582351 From tsayao at openjdk.org Mon Dec 25 20:48:09 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 25 Dec 2023 20:48:09 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v17] In-Reply-To: References: Message-ID: <_TxY4SdwrrDUcS3GiT7rcYuukW81kRIueh-8jLUG9S0=.118128fe-88ef-48de-a13b-7353bea92fa5@github.com> > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Add check for jview ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1080/files - new: https://git.openjdk.org/jfx/pull/1080/files/d6622260..f6ed2782 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=16 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=15-16 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From tsayao at openjdk.org Mon Dec 25 20:48:10 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 25 Dec 2023 20:48:10 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v13] In-Reply-To: References: Message-ID: On Sat, 16 Dec 2023 23:49:00 GMT, Thiago Milczarek Sayao wrote: >> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 486: >> >>> 484: CHECK_JNI_EXCEPTION(mainEnv) >>> 485: >>> 486: if (press && key > 0) { // TYPED events should only be sent for printable characters. >> >> A handler for the PRESS event might close the window. In that case `jview` will be set to zero before you send out the TYPED event. You should do another check for that here. >> >> See [JDK-8301219](https://bugs.openjdk.org/browse/JDK-8301219) for some sample code. I'll be submitting a fix for that bug just as soon as I get a test case working reliably. > > There's a check before. > > > if (!jview) { > return; > } I see what you mean now. Fixed it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1436151433 From thiago.sayao at gmail.com Mon Dec 25 22:54:45 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 25 Dec 2023 19:54:45 -0300 Subject: EGL on JavaFX/X11 Message-ID: Hi, I did manage to run JavaFX with EGL on Linux/X11. It's required for Wayland. Would it be useful to anticipate it for X11? Using the 3DLighting sample I did not see any significant performance differences. Gtk: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540 Firefox: https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/ Depending on feedback, I can work on a PR. -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvos at openjdk.org Tue Dec 26 09:59:17 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 26 Dec 2023 09:59:17 GMT Subject: RFR: [WIP] 8319779: SystemMenu: memory leak due to listener never being removed [v5] In-Reply-To: References: Message-ID: > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Revert WeakInvalidationListeners and use new listener resource management approach. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1283/files - new: https://git.openjdk.org/jfx/pull/1283/files/47f4d65d..9b1133cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=03-04 Stats: 18 lines in 1 file changed: 6 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From jvos at openjdk.org Tue Dec 26 10:27:51 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 26 Dec 2023 10:27:51 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v4] In-Reply-To: <24RFFbrL_x5VNCiV8ApQkbdomoIU1rUASL_jZq6N2Y8=.ffdda2b7-bcfb-4089-b0a4-291d763a88d5@github.com> References: <5M-OrTlQ94IWUqnb3pgHAtK0V7c-Ev7S80ak01i_Oic=.945784e1-8a51-480e-b530-f9a55bf2b03b@github.com> <24RFFbrL_x5VNCiV8ApQkbdomoIU1rUASL_jZq6N2Y8=.ffdda2b7-bcfb-4089-b0a4-291d763a88d5@github.com> Message-ID: On Tue, 19 Dec 2023 13:25:38 GMT, John Hendrikx wrote: >> As for the memory leak issue: there were several. The first commit in this PR fixed a clear memory leak, but the one that is still left is not described in the issue. >> It occurs because whenever the SystemMenuBar is shown after it was not shown, all MenuItems will be readded using `GlassSystemMenu.setMenu`. This will invoke `GlassSystemMenu.insertMenuItem(... MenuItemBase menuItem...)` >> Inside this method, platform-specific menuItems will be created, that will adapt when the `MenuItemBase` properties are changing. The annoying thing, as stated in the first comment of that method, is that we don't know if the passed `MenuItemBase` instance was previously used in this method (in which case the listeners are regisered to this instance) or not. That is why for example the `visibilityListener` is unconditionally removed (even if we don't know if it was ever added) and then added. >> We can do the same for the other properties (preventing the use of weak listeners), but it would be nice if we could address this case using the api introduced in the deterministic listeners management (I would very much prefer that over weak listeners). >> I'm not too familiar with the new API though, but it seems difficult to do this _inside_ this method, as we would still add a listener each time the method is invoked with an item that already has a listener registered? > >> As for the memory leak issue: there were several. The first commit in this PR fixed a clear memory leak, but the one that is still left is not described in the issue. It occurs because whenever the SystemMenuBar is shown after it was not shown, all MenuItems will be readded using `GlassSystemMenu.setMenu`. This will invoke `GlassSystemMenu.insertMenuItem(... MenuItemBase menuItem...)` Inside this method, platform-specific menuItems will be created, that will adapt when the `MenuItemBase` properties are changing. The annoying thing, as stated in the first comment of that method, is that we don't know if the passed `MenuItemBase` instance was previously used in this method (in which case the listeners are regisered to this instance) or not. That is why for example the `visibilityListener` is unconditionally removed (even if we don't know if it was ever added) and then added. We can do the same for the other properties (preventing the use of weak listeners), but it would be nice if w e could address this case using the api introduced in the deterministic listeners management (I would very much prefer that over weak listeners). I'm not too familiar with the new API though, but it seems difficult to do this _inside_ this method, as we would still add a listener each time the method is invoked with an item that already has a listener registered? > > It's still a bit unclear for me. So what I write below may be off the mark. > > From what I can see, `setMenus` will first remove all items, then re-add them. The `clearMenu` function seems like a logical place to remove listeners that may be present. The problem is where to keep track off the listeners. I see a few options: > > 1. Track the listeners in a few `Map`s in `GlassSystemMenu`, something like `Map`, with a different `Map` for each listener type (text, disabled, mnemonic, etc). Or something more elaborate with a listener holder, nested maps, etc. > > These maps can then iterated when `setMenus` is called to clear out ALL the listeners (or as part of `clearMenu`. > > 2. Similar to above but store the listener information in the properties of `Menu` > > 3. Using the new resource management system. Attach all listeners with a `when` condition based on a `SimpleBooleanProperty` that you **replace** each time `setMenus` is called (replacement is needed in this case as we don't know if the menus were used before or not, but it is still relatively clean). > > The last one works like this: > > Create ... Thanks @hjohn for the clear explanation. I replaced the Weak listeners with the new listener resource management approach, and that works fine. I'm still looking into adding a test. The challenge is that the (previously) uncollected items are of type `com.sun.glass.ui.MenuItem`, and afaik we can't use JMemoryBuddy to check the collectable state of instances on the heap that we don't have a reference to ourselves. I see 2 options: * a unit test, with new shim classes so that we get access to `com.sun.glass.ui.MenuItem` from the test. The problem here is that this quickly becomes a test for the shim class and not for the real classes * a systemtest that can somehow inspect the heap and count the instances of `com.sun.glass.ui.MenuItem` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1869439147 From jhendrikx at openjdk.org Tue Dec 26 15:32:47 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 26 Dec 2023 15:32:47 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v4] In-Reply-To: References: <5M-OrTlQ94IWUqnb3pgHAtK0V7c-Ev7S80ak01i_Oic=.945784e1-8a51-480e-b530-f9a55bf2b03b@github.com> <24RFFbrL_x5VNCiV8ApQkbdomoIU1rUASL_jZq6N2Y8=.ffdda2b7-bcfb-4089-b0a4-291d763a88d5@github.com> Message-ID: On Tue, 26 Dec 2023 10:24:42 GMT, Johan Vos wrote: > I'm still looking into adding a test. The challenge is that the (previously) uncollected items are of type `com.sun.glass.ui.MenuItem`, and afaik we can't use JMemoryBuddy to check the collectable state of instances on the heap that we don't have a reference to ourselves. I see 2 options: > > * a unit test, with new shim classes so that we get access to `com.sun.glass.ui.MenuItem` from the test. The problem here is that this quickly becomes a test for the shim class and not for the real classes > * a systemtest that can somehow inspect the heap and count the instances of `com.sun.glass.ui.MenuItem` Perhaps add a package private method to get access to `GlassSystemMenu#systemMenus` (or use reflection)? I think you could then put a weak reference on the returned list (or items) and see if that disappears. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1869617031 From mfox at openjdk.org Tue Dec 26 16:17:50 2023 From: mfox at openjdk.org (Martin Fox) Date: Tue, 26 Dec 2023 16:17:50 GMT Subject: Integrated: 8301219: JavaFX crash when closing with the escape key In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 00:58:56 GMT, Martin Fox wrote: > While processing a key down event the Glass GTK code sends out PRESSED and TYPED KeyEvents back to back. If the stage is closed during the PRESSED event the code will end up referencing freed memory while sending out the TYPED event. This can lead to intermittent crashes. > > In GlassApplication.cpp the EventCounterHelper object ensures the WindowContext isn't deleted while processing an event. Currently the helper object is being created *after* IME handling instead of before. If the IME is enabled it's possible for the WindowContext to be deleted in the middle of executing a number of keyboard-related events. > > The fix is simple; instantiate the EventCounterHelper object earlier. There isn't always a WindowContext so I tweaked the EventCounterHelper to do nothing if the context is null. > > To make the crash more reproducible I altered the WindowContext such that when it's deleted the freed memory is filled with 0xCC. This made the crash more reproducible and allowed me to test the fix. I did the same with GlassView since that's the only other Glass GTK class that's instantiated with `new` and discarded with `delete`. This pull request has now been integrated. Changeset: 2493a23e Author: Martin Fox URL: https://git.openjdk.org/jfx/commit/2493a23e2dc5ff8694ab4a1bed06fe73466edaf9 Stats: 201 lines in 5 files changed: 192 ins; 2 del; 7 mod 8301219: JavaFX crash when closing with the escape key 8087368: java runtime environment error when trying to execute showAndWait() function Reviewed-by: kcr, tsayao ------------- PR: https://git.openjdk.org/jfx/pull/1307 From mfox at openjdk.org Tue Dec 26 16:54:07 2023 From: mfox at openjdk.org (Martin Fox) Date: Tue, 26 Dec 2023 16:54:07 GMT Subject: RFR: 8189282: JavaFX: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows Message-ID: When reporting input method candidate position the code in GlassViewEventHandler is not applying the platform scale factors. This is causing incorrect IM positions to be reported to glass on hi-dpi monitors. This PR a no-op on Mac since the platform scale factors are always 1.0. I don't think it affects the current Linux XIM code at all but XIM is so out-of-date it has become difficult to test. PR #1080 will replace the old XIM code and needs this fix to work properly on hi-dpi screens. ------------- Commit messages: - Removed debug output - Applying screen scale factors when positioning IM window Changes: https://git.openjdk.org/jfx/pull/1311/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1311&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8189282 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1311.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1311/head:pull/1311 PR: https://git.openjdk.org/jfx/pull/1311 From mail2akash97 at gmail.com Tue Dec 26 17:45:28 2023 From: mail2akash97 at gmail.com (Keerthivasan Raghavan) Date: Tue, 26 Dec 2023 23:15:28 +0530 Subject: Info on OpenJFX architecture Message-ID: Hi All, I am a newbie to the desktop/embedded linux graphics and widget toolkit. The following is a list of questions about how OpenJFX is architected/designed/implemented: * How does openjfx manage the lifecycle of windows/surfaces/graphics-context(EGL/OpenGL) to draw into? What is the (design and implementation)/architecture of the window system abstraction used by OpenJFX? Any links to code snippets inside OpenJFX showing the creation/management of an X11-Window/Wayland-Surface would help. References: * GTK uses GDK(https://docs.gtk.org/gtk4/drawing-model.html) for managing windowing abstraction. * GLFW, a cross platform (window + graphics context + input) management: https://www.glfw.org/ * Microsoft Windows win32 API: https://learn.microsoft.com/en-us/windows/win32/learnwin32/creating-a-window, https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-createwindowexa * How are frames created using drawing operations? What is the abstraction used to express the content of the frame? Any code/design links please. References: * GTK uses GSK(https://docs.gtk.org/gsk4/) for building the scene graph that can be rendered as a frame. * Windows reference: https://learn.microsoft.com/en-us/windows/win32/learnwin32/your-first-direct2d-program * How is event management done in OpenGFX ? Any code/design links please. Reference: * GTK uses an main eventloop https://docs.gtk.org/glib/main-loop.html . * How are widgets drawn ? How are events dispatched to widgets and how do widgets react to events ? How is the application widget UI state stored and what is the corresponding memory management for storing the UI/widget state ? Does the UI state get modeled as a scene graph ? Any code/design links please. Reference: * https://learn.microsoft.com/en-us/windows/win32/learnwin32/retained-mode-versus-immediate-mode Please feel free to reply with code links, design docs, wikis or articles of the web. Thank you, Keerthivasan Raghavan -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.sayao at gmail.com Tue Dec 26 17:52:05 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 26 Dec 2023 14:52:05 -0300 Subject: EGL on JavaFX/X11 In-Reply-To: References: Message-ID: Hi, For anyone interested: https://github.com/tsayao/jfx/tree/egl It's just a quick port to make it run, still needs work. Em seg., 25 de dez. de 2023 ?s 19:54, Thiago Milczarek Say?o < thiago.sayao at gmail.com> escreveu: > Hi, > > I did manage to run JavaFX with EGL on Linux/X11. > > It's required for Wayland. Would it be useful to anticipate it for X11? > > Using the 3DLighting sample I did not see any significant performance > differences. > > Gtk: > https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540 > > Firefox: > > https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/ > > Depending on feedback, I can work on a PR. > > -- Thiago. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Tue Dec 26 18:33:49 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 26 Dec 2023 18:33:49 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text In-Reply-To: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: On Sun, 10 Sep 2023 20:50:18 GMT, John Hendrikx wrote: > There are a number of tickets open related to text rendering: > > https://bugs.openjdk.org/browse/JDK-8314215 > > https://bugs.openjdk.org/browse/JDK-8145496 > > https://bugs.openjdk.org/browse/JDK-8129014 > > They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). > > The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). > > If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. > > TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. > > For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. > > The above behavior has NOT changed, is pretty standard for wrapped text controls, and IMHO does not need further attent... keep open ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1869707712 From thiago.sayao at gmail.com Tue Dec 26 20:40:48 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 26 Dec 2023 17:40:48 -0300 Subject: Info on OpenJFX architecture In-Reply-To: References: Message-ID: Hi Keerthivasan, Answers below. Em ter., 26 de dez. de 2023 ?s 15:32, Keerthivasan Raghavan < mail2akash97 at gmail.com> escreveu: > Hi All, > > I am a newbie to the desktop/embedded linux graphics and widget toolkit. > > The following is a list of questions about how OpenJFX is > architected/designed/implemented: > > * How does openjfx manage the lifecycle of > windows/surfaces/graphics-context(EGL/OpenGL) to draw into? > What is the (design and implementation)/architecture of the window system > abstraction used by OpenJFX? > Any links to code snippets inside OpenJFX showing the > creation/management of an X11-Window/Wayland-Surface would help. > References: > * GTK uses GDK(https://docs.gtk.org/gtk4/drawing-model.html) for managing > windowing abstraction. > * GLFW, a cross platform (window + graphics context + input) management: > https://www.glfw.org/ > * Microsoft Windows win32 API: > https://learn.microsoft.com/en-us/windows/win32/learnwin32/creating-a-window, > > > https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-createwindowexa > > Each platform has its implementation.The abstraction layer is called "glass". In the case of linux, gtk is used. Pure wayland (without XWayland) is not supported yet - and, from my experience, gtk will probably not be used. Look for glass_window.cpp for the Gtk backend. > * How are frames created using drawing operations? > What is the abstraction used to express the content of the frame? > Any code/design links please. > References: > * GTK uses GSK(https://docs.gtk.org/gsk4/) for building the scene graph > that can be rendered as a frame. > * Windows reference: > https://learn.microsoft.com/en-us/windows/win32/learnwin32/your-first-direct2d-program > > The rendering abstraction layer is called "prism". I'm not sure how the scene graph is translated into rendering artifacts. On Linux, GLX is used to glue to OpenGL on a sublayer of prism called "es2". If Wayland is implemented, it will have to use EGL. Windows uses direct3d Mac will use Metal (I think it's under development). > > * How is event management done in OpenGFX ? > Any code/design links please. > Reference: > * GTK uses an main eventloop https://docs.gtk.org/glib/main-loop.html . > Desktop events originate from glass and it's platform dependent. Those events are translated into JavaFX event system. In the case of Linux it also uses GTK eventloop. > > * How are widgets drawn ? How are events dispatched to widgets and how do > widgets react to events ? > How is the application widget UI state stored and what is the > corresponding memory management for storing the UI/widget state ? > Does the UI state get modeled as a scene graph ? > Any code/design links please. > Reference: > * > https://learn.microsoft.com/en-us/windows/win32/learnwin32/retained-mode-versus-immediate-mode > > Widgets are drawn using the scene graph. I think a Node is the basic element (on the public API). In the case of Linux, javafx draws directly into the window/surface (that is passed by glass). This is the case of hardware accelerated rendering. If software is used, it generates a bitmap buffer that is passed to glass. In the case of linux, cairo is used. > Please feel free to reply with code links, design docs, wikis or articles > of the web. > > Thank you, > Keerthivasan Raghavan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfox at openjdk.org Tue Dec 26 23:42:56 2023 From: mfox at openjdk.org (Martin Fox) Date: Tue, 26 Dec 2023 23:42:56 GMT Subject: RFR: 8189282: JavaFX: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows [v2] In-Reply-To: References: Message-ID: > When reporting input method candidate position the code in GlassViewEventHandler is not applying the platform scale factors. This is causing incorrect IM positions to be reported to glass on hi-dpi monitors. > > This PR a no-op on Mac since the platform scale factors are always 1.0. I don't think it affects the current Linux XIM code at all but XIM is so out-of-date it has become difficult to test. PR #1080 will replace the old XIM code and needs this fix to work properly on hi-dpi screens. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: IM coordinates are relative to main screen ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1311/files - new: https://git.openjdk.org/jfx/pull/1311/files/2e61be93..401f5117 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1311&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1311&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1311.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1311/head:pull/1311 PR: https://git.openjdk.org/jfx/pull/1311 From mfox at openjdk.org Wed Dec 27 00:04:54 2023 From: mfox at openjdk.org (Martin Fox) Date: Wed, 27 Dec 2023 00:04:54 GMT Subject: RFR: 8301893: IME window position is off on secondary screen Message-ID: The Mac screen coordinate system is inverted on the y-axis compared to JavaFX so glass needs to flip the y coordinate. IM coordinates are relative to the primary screen which is NSScreen.screens[0], not NSScreen.mainScreen (mainScreen is the screen that contains the window that has focus). ------------- Commit messages: - Correctly invert y-coordinate on secondary monitors Changes: https://git.openjdk.org/jfx/pull/1313/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1313&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301893 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1313.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1313/head:pull/1313 PR: https://git.openjdk.org/jfx/pull/1313 From john.hendrikx at gmail.com Wed Dec 27 05:53:56 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 27 Dec 2023 06:53:56 +0100 Subject: Caret animation Message-ID: <32eab062-6703-b23d-78d7-eab25a4813f4@gmail.com> In light of a possible future Behavior API, I took a close look at the "complicated" behaviors surrounding TextFields and TextAreas. One thing that came out of this is that caret animation is controlled by the behaviors by looking at key presses and keys typed. It is a very convoluted way of doing this as there is a much simpler rule that governs caret animation: *when the caret moves, animation should be reset* This is how controls do it in browsers and on Windows, and it makes much more sense. The caret only needs highlighting when it actually changed position, and can remain animated when it doesn't. This also means that caret blinking can simply be a concern of the Skin, as it can listen for caret position changes.? This also makes more sense.? Replacing the Behavior but keeping the same Skin should not break caret blinking. Currently, the behaviors will wrap all possible key pressed/typed events to stop the blinking, but it gets it wrong in many situations (when the caret didn't actually move, or when a key press was not consumed or didn't do anything, or using keypad navigation which "forgets" to wrap it in the start/stop animation logic). It feels like a big hack when there is such an obvious alternative. I've created this ticket to address this: https://bugs.openjdk.org/browse/JDK-8322748 One of the immediate benefits (aside from solving all caret animation bugs) is probably a memory reduction as it removes a wrapper around every key press/type mapping... --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfox at openjdk.org Fri Dec 29 18:56:53 2023 From: mfox at openjdk.org (Martin Fox) Date: Fri, 29 Dec 2023 18:56:53 GMT Subject: RFR: 8090267: JFXPanel Input Problem In-Reply-To: References: Message-ID: On Tue, 4 Jul 2023 05:54:54 GMT, Prasanta Sadhukhan wrote: > When Japanse (IME on) is inputted to the TextFIeld, which is on JFXPanel, > small window for inputting appears on top-left side of screen > > ![image](https://github.com/openjdk/jfx/assets/43534309/65833d59-528e-4087-9992-9f86b8b8c47f) > > For swing-interop case, WmImeStartComposition starts composition in native ImmSetCompositionWindow window as "m_useNativeCompWindow" below is true for FX > https://github.com/openjdk/jdk/blob/514816ed7d7dea1fb13d32b80aef89774bee13d3/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#L3957 > > m_useNativeCompWindow is true because during sun.awt.im.InputContext#focusGained() calls activateInputMethod which calls WInputMethod.activate() which calls haveActiveClient() which checks for > clientComponent.getInputMethodRequests(). > Now, in JFXPanel, getInputMethodRequests() returns null as setEmbeddedScene() is not called yet. > Since getInputMethodRequests() returns null, haveActiveClient() is false which calls enableNativeIME() with 1 [thereby native composition window is enabled] > https://github.com/openjdk/jdk/blob/514816ed7d7dea1fb13d32b80aef89774bee13d3/src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java#L316 > > Proposed fix is to ensure there is an active client "initially" so that enableNativeIME() is called with 0 and no native compostion window is shown. > getInputMethodRequests() is called in setEmbeddedScene() so as to make sure getInputMethodRequest() is initialised to correct "InputMethodSupport.InputMethodRequestsAdapter.fxRequests" object and not NULL. > > AFter fix > ![image](https://github.com/openjdk/jfx/assets/43534309/ec3d8343-9295-4950-885b-f9983b9b017a) It turns out this PR didn't introduce new problems, it just exposed existing ones. The AWT EventQueue thread is calling into the InputMethodRequests at the same time as the JavaFX thread is updating and drawing the text field. If the timing is right (or wrong) both threads can trigger glyph layout in the same Text object at the same time. The result is the sort of erratic behavior seen here. I've entered [JDK-8322784](https://bugs.openjdk.org/browse/JDK-8322784). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1169#issuecomment-1872276763 From nlisker at openjdk.org Sat Dec 30 02:32:48 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 30 Dec 2023 02:32:48 GMT Subject: RFR: 8092272: [D3D 3D] Need a robust 3D states management for texture [v2] In-Reply-To: References: Message-ID: <38kBL4xkFD2SLxLY4j-ZhGVDhOb_UKd_WXc3MzwcQZs=.a9b0f218-a535-49c9-91f1-9ba70b761b74@github.com> On Fri, 10 Nov 2023 23:39:21 GMT, Nir Lisker wrote: >> Moves the filter setting of the samplers from the device parameters configuration to the use-site, allowing for dynamic changes in the sampler. This PR does internal plumbing work only to bring it close to the ES2 pipeline. A followup PR will create the public API. >> >> Summary of the changes: >> * Created a new (internal for now) `TextureData` object that is intended to contain all the data of texture (map) of `PhongMaterial`, such as filters, addressing, wrapping mode, mipmaps etc. **This PR deals only with filters** as a starting point, more settings can be added later. >> * Creates an update mechanism from the Java side material to the native D3D layer. The public API `PhoneMaterial` is *not* changed yet. The peer `NGPhongMaterial` is configured to receive update from the public `PhongMaterial` when the public API is created via new `ObjectProperty` properties. >> * Small refactoring in the D3D layer with a new map types enum to control the texture settings more easily. >> >> The JBS issue lists some regressions in a comment, but I couldn't reproduce them. It looks like the sampler settings needed to be added anywhere, and that was the easiest to do at the time. Now they were just moved. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Keep open. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1281#issuecomment-1872431080 From florian.kirmaier at gmail.com Sun Dec 31 14:00:39 2023 From: florian.kirmaier at gmail.com (Florian Kirmaier) Date: Sun, 31 Dec 2023 15:00:39 +0100 Subject: Performance Regression in 21 - CSS In-Reply-To: References: Message-ID: Hi Everyone, Sorry for the delay - but I couldn?t find the time to extract the TestApplication for this bug. Luckily, I found another application, which is also open source, which is affected by the application. I'm speaking about https://www.jfx-central.com/ - both the desktop and web versions are affected. I?ve seen a performance deterioration of 10x when switching pages when using JavaFX21 compared to JavaFX20. I?ve created a ticket with further instructions on how to test it: https://bugs.openjdk.org/browse/JDK-8322795 Greetings Florian Kirmaier On Fri, 27 Oct 2023 at 21:31, Andy Goryachev wrote: > Please create a ticket, Florian. Would it be possible to profile the > application when scrolling? > > > > Thank you > > -andy > > > > > > > > *From: *openjfx-dev on behalf of Florian > Kirmaier > *Date: *Friday, October 27, 2023 at 04:20 > *To: *openjfx-dev at openjdk.java.net > *Subject: *Performance Regression in 21 - CSS > > Hi everyone, > > I've noticed that some parts of one of my applications is significantly > slower with 21. It's fast with 20. > The application heavily uses (and reuses) TextFlow with a Cell pattern. > When I scroll, it is smooth with 20, but has big freezes with 21. > > I've tried all the commits that happened in between, and pin-pointed it > down to the following: > ticket: https://bugs.openjdk.org/browse/JDK-8304959 > PR: https://github.com/openjdk/jfx/pull/1070 > commit: > https://github.com/openjdk/jfx21u/commit/3fa02ee96a6dadbc20cacbf399a2d65df708eee1 > > > According to the description and the discussion in the PR - this wasn't > supposed to change any performance. > Is this regression known? > Otherwise, I should create a ticket for it. > > Greetings Florian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crschnick at xpipe.io Sun Dec 31 14:24:14 2023 From: crschnick at xpipe.io (Christopher Schnick) Date: Sun, 31 Dec 2023 15:24:14 +0100 Subject: Performance Regression in 21 - CSS In-Reply-To: References: Message-ID: <8cdf6073-0b62-4ffc-8da3-56750416fc91@xpipe.io> Hello, I just tested this with our JavaFX application and can confirm that there are massive differences. It takes around 1-2 seconds to completely apply all application stylesheets in JavaFX 20 but takes around 6-7 seconds in JavaFX 21. On 12/31/2023 3:00 PM, Florian Kirmaier wrote: > Hi Everyone, > > Sorry for the delay - but I couldn?t find the time to extract the > TestApplication for this bug. > Luckily, I found another application, which is also open source, which > is affected by the application. > > I'm speaking about https://www.jfx-central.com/?- both the desktop and > web versions are affected. > I?ve seen a performance deterioration of 10x when switching pages when > using JavaFX21 compared to JavaFX20. > > I?ve created a ticket with further instructions on how to test it: > https://bugs.openjdk.org/browse/JDK-8322795 > > Greetings > > Florian Kirmaier > > On Fri, 27 Oct 2023 at 21:31, Andy Goryachev > wrote: > > Please create a ticket, Florian.? Would it be possible to profile > the application when scrolling? > > Thank you > > -andy > > *From: *openjfx-dev on behalf of > Florian Kirmaier > *Date: *Friday, October 27, 2023 at 04:20 > *To: *openjfx-dev at openjdk.java.net > *Subject: *Performance Regression in 21 - CSS > > Hi everyone, > > I've noticed that some parts of one of my applications is > significantly slower with 21. It's fast with 20. > The application heavily uses (and reuses) TextFlow with a Cell > pattern. > When I scroll, it is smooth with 20, but has big freezes with 21. > > I've tried all the commits that happened in between, and > pin-pointed it down to the following: > ticket: https://bugs.openjdk.org/browse/JDK-8304959 > PR: https://github.com/openjdk/jfx/pull/1070 > commit: > https://github.com/openjdk/jfx21u/commit/3fa02ee96a6dadbc20cacbf399a2d65df708eee1 > > > According to the description and the discussion in the PR - this > wasn't supposed to change any performance. > Is this regression known? > Otherwise, I should create a ticket for it. > > Greetings Florian > -------------- next part -------------- An HTML attachment was scrubbed... URL: