Re: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
On Mon, 2 Aug 2021 21:53:02 GMT, Sergey Bylokhov wrote: >> Yes, and we need this call here to initialise content view with correct >> default value >> CPlatformWindow.java:931 contentView.setWindowLayerOpaque(isOpaque); > > I need to look at it closely, I do not understand why we made the native > layer opaque=NO by default while the java code uses opaque=true by default. > And then we reset the native code from NO to yes by the code above. Why we > cannot make both native/java use true/YES and when necessary it will be reset > to false/NO by the existing code(via LWWindowPeer.setOpaque() and > LWWindowPeer.updateOpaque?) > BTW Probably implementation of LWWindowPeer.setTextured() should call the > updateOpaque() as well. Yes, sounds reasonable. Moreover, It was my initial attempt but I faced with some regressions in SwingSet2 demo. In some cases background of tree nodes become black and this artifact was reproducible only if some other tabs were clicked before. It was hot time for jdk17 so I decided not to fight with this regression. Now we have more time, so I can spend more time on this. - PR: https://git.openjdk.java.net/jdk/pull/4946
Re: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v9]
On Mon, 2 Aug 2021 10:00:10 GMT, Artem Semenov wrote: >> In the example, you use a JList class, and the checks in the code above >> works, but if some other "AccessibleJList" class will be used then it will >> not work, right? This is the reason why implementations of a11y classes >> usually use specific interfaces like "AccessibleJList". > > Yes, this will not work with a custom list not inherited from JList. > Unfortunately AccessibleJList is not perfect and the functionality you need > is not there. > If you have a better solution, please share it. - Could you please advice on > what we can do here? This is what I meant in the first message, "a11y interface miss setSelectedIndex method". I suggest filing a separate issue to accumulate such use cases and then fix them by adding additional methods to a11y interfaces. Probably something similar will be found in the Table/etc. - PR: https://git.openjdk.java.net/jdk/pull/4412
Re: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
On Mon, 2 Aug 2021 20:04:43 GMT, Alexey Ushakov wrote: >> src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java line 199: >> >>> 197: >>> 198: platformWindow.initialize(target, this, ownerDelegate); >>> 199: platformWindow.setOpaque(!isTranslucent()); >> >> !isTranslucent() uses the opaque flag which will be initialised in the code >> below(see setOpaque(getTarget().isOpaque());) > > Yes, and we need this call here to initialise content view with correct > default value > CPlatformWindow.java:931 contentView.setWindowLayerOpaque(isOpaque); I need to look at it closely, I do not understand why we made the native layer opaque=NO by default while the java code uses opaque=true by default. And then we reset the native code from NO to yes by the code above. Why we cannot make both native/java use true/YES and when necessary it will be reset to false/NO by the existing code(via LWWindowPeer.setOpaque() and LWWindowPeer.updateOpaque?) BTW Probably implementation of LWWindowPeer.setTextured() should call the updateOpaque() as well. - PR: https://git.openjdk.java.net/jdk/pull/4946
Re: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
On Mon, 2 Aug 2021 18:26:45 GMT, Sergey Bylokhov wrote: >> Keep MTLLayer opacity in sync with window content view >> Keep layer translucent for translucent windows > > src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java line 199: > >> 197: >> 198: platformWindow.initialize(target, this, ownerDelegate); >> 199: platformWindow.setOpaque(!isTranslucent()); > > !isTranslucent() uses the opaque flag which will be initialised in the code > below(see setOpaque(getTarget().isOpaque());) Yes, and we need this call here to initialise content view with correct default value CPlatformWindow.java:931 contentView.setWindowLayerOpaque(isOpaque); - PR: https://git.openjdk.java.net/jdk/pull/4946
Re: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
On Fri, 30 Jul 2021 15:39:19 GMT, Alexey Ushakov wrote: > Keep MTLLayer opacity in sync with window content view > Keep layer translucent for translucent windows src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java line 199: > 197: > 198: platformWindow.initialize(target, this, ownerDelegate); > 199: platformWindow.setOpaque(!isTranslucent()); !isTranslucent() uses the opaque flag which will be initialised in the code below(see setOpaque(getTarget().isOpaque());) - PR: https://git.openjdk.java.net/jdk/pull/4946
Re: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module
On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov wrote:
> This is a request to clean up a desktop module as was done in JDK-8233884 for
> "java.base" module.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be done more efficiently(x20 time faster) with use of
> java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
>
> The later variant also makes the code cleaner, as it is known not to throw
> UnsupportedEncodingException in contrary to the former variant.
>
> Tested by the desktop headless/headful tests on linux/windows.
Marked as reviewed by stsypa...@github.com (no known OpenJDK username).
-
PR: https://git.openjdk.java.net/jdk/pull/4951
Integrated: 8268113: Re-use Long.hashCode() where possible
On Wed, 2 Jun 2021 14:10:38 GMT, Сергей Цыпанов wrote: > There is a few JDK classes duplicating the contents of Long.hashCode() for > hash code calculation. They should explicitly delegate to Long.hashCode(). This pull request has now been integrated. Changeset: 6a3f8343 Author:Sergey Tsypanov Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/6a3f8343bc0e92c29a87c5840cbef9ab2988f153 Stats: 10 lines in 6 files changed: 0 ins; 4 del; 6 mod 8268113: Re-use Long.hashCode() where possible Reviewed-by: redestad - PR: https://git.openjdk.java.net/jdk/pull/4309
Re: RFR: 8268113: Re-use Long.hashCode() where possible [v11]
On Mon, 26 Jul 2021 08:27:14 GMT, Сергей Цыпанов wrote: >> There is a few JDK classes duplicating the contents of Long.hashCode() for >> hash code calculation. They should explicitly delegate to Long.hashCode(). > > Сергей Цыпанов 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 13 additional > commits since the last revision: > > - Merge branch 'master' into 8268113 > - 8270160 Revert changes in BitSet.hashCode > - Merge branch 'master' into 8268113 > - 8270160 Revert changes in BitSet.hashCode > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - ... and 3 more: > https://git.openjdk.java.net/jdk/compare/1d801fa0...bd762b7d All changes look good to me, though 3rd party sources like xerces/.../DoubleDV.java should probably be dealt with in the upstream first. @AlanBateman probably knows who maintains and downstreams this usually (or whether we are now practically maintaining a fork of xerces)? - Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4309
Re: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v9]
On Mon, 2 Aug 2021 05:38:42 GMT, Sergey Bylokhov wrote: >> Unfortunately, the current a11y interface does not allow this action. >> As for the custom AccessibleJListChild, I prepared a [sample >> project](https://github.com/savoptik/AccessibilityJListItemA11yExample) in >> which I implemented a custom child. The experiment showed that there are no >> negative consequences. The custom child works as intended. > > In the example, you use a JList class, and the checks in the code above > works, but if some other "AccessibleJList" class will be used then it will > not work, right? This is the reason why implementations of a11y classes > usually use specific interfaces like "AccessibleJList". Yes, this will not work with a custom list not inherited from JList. Unfortunately AccessibleJList is not perfect and the functionality you need is not there. If you have a better solution, please share it. - Could you please advice on what we can do here? - PR: https://git.openjdk.java.net/jdk/pull/4412
Re: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v9]
On Mon, 2 Aug 2021 05:50:09 GMT, Sergey Bylokhov wrote: >> Done > > I suggest doing the opposite, leave the CHECK_EXCEPTION and remove the chech > and the logging. The CHECK_EXCEPTION is better since it can be configured > via properties, and it will chech itself on what thread the current code is > executed. Done - PR: https://git.openjdk.java.net/jdk/pull/4412
Re: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v9]
> 8267385: Create NSAccessibilityElement implementation for > JavaComponentAccessibility > This pull request contains solutions for the following tickets: > * JDK-8267385 Create NSAccessibilityElement implementation for > JavaComponentAccessibility; > * JDK-8262031 Create implementation for NSAccessibilityNavigableStaticText > protocol; > * JDK-8264287 Create implementation for NSAccessibilityComboBox protocol peer; > * JDK-8264303 Create implementation for NSAccessibilityTabGroup protocol peer; > * JDK-8264292 Create implementation for NSAccessibilityList protocol peer; > * JDK-8267387 Create implementation for NSAccessibilityOutline protocol; > * JDK-8267388 Create implementation for NSAccessibilityTable protocol. Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: 1. Fixed problems with vertical navigation in table cells; 2. I suggest doing the opposite, leave the CHECK_EXCEPTION and remove the chech and the logging. The CHECK_EXCEPTION is better since it can be configured via properties, and it will chech itself on what thread the current code is executed. - Changes: - all: https://git.openjdk.java.net/jdk/pull/4412/files - new: https://git.openjdk.java.net/jdk/pull/4412/files/65053348..a13d6a6b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4412&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4412&range=07-08 Stats: 19 lines in 4 files changed: 1 ins; 11 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4412.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4412/head:pull/4412 PR: https://git.openjdk.java.net/jdk/pull/4412
Re: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v8]
On Mon, 2 Aug 2021 05:53:25 GMT, Sergey Bylokhov wrote: >> Done > > But the code above still exits or it is a github glitch? By convention with @ azuev-java, we try to either not change at all, or change the minimum legacy code. - PR: https://git.openjdk.java.net/jdk/pull/4412
