RFR: 8258788: incorrect response to change in window insets [lanai]
Perform replaceSurfaceData on insets change - Commit messages: - 8258788: incorrect response to change in window insets [lanai] Changes: https://git.openjdk.java.net/jdk/pull/3390/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3390=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258788 Stats: 167 lines in 2 files changed: 167 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3390.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3390/head:pull/3390 PR: https://git.openjdk.java.net/jdk/pull/3390
Withdrawn: 8258788: incorrect response to change in window insets [lanai]
On Thu, 1 Apr 2021 14:38:52 GMT, Alexey Ushakov wrote: > Dynamically change MTLLayer insets depending on FULL_WINDOW_CONTENT property. > MTLLayer.h header cleanup. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/3308
Re: RFR: 8258788: incorrect response to change in window insets [lanai] [v4]
> Dynamically change MTLLayer insets depending on FULL_WINDOW_CONTENT property. > MTLLayer.h header cleanup. Alexey Ushakov 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: 8258788: incorrect response to change in window insets [lanai] Perform replaceSurfaceData on insets change - Changes: - all: https://git.openjdk.java.net/jdk/pull/3308/files - new: https://git.openjdk.java.net/jdk/pull/3308/files/52fc75e7..ed5e6814 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3308=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3308=02-03 Stats: 35 lines in 8 files changed: 17 ins; 17 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3308.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3308/head:pull/3308 PR: https://git.openjdk.java.net/jdk/pull/3308
Re: RFR: 8258788: incorrect response to change in window insets [lanai]
On Tue, 6 Apr 2021 12:51:47 GMT, Alexey Ushakov wrote: >>> Is it possible to automatically test it? >> >> Yes, just added the test. > >> @avu Test passes without fix also. > @jayathirthrao Could you provide the details about your configuration along > with parameters passed to jtreg ? > @avu I am running test in 13 inch Macbook Early 2015 with integrated Intel > Iris Graphics 6100. > jtreg command i am using "jtreg -jdk: -Dsun.java2d.metal=true > " @jayathirthrao I'm not sure that -Dsun.java2d.metal had been passed to the test JVM. I rechecked with slightly different command line and the test fails without the fix jtreg -ignore:quiet -v -a -xml -vmoptions:"-Dsun.java2d.metal=True " -testjdk:path_to_jdk path_to_test - PR: https://git.openjdk.java.net/jdk/pull/3308
Re: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol
On Mon, 5 Apr 2021 18:47:25 GMT, Pankaj Bansal wrote: >> Ok, please file a similar bug for the windows platform. > > @mrserb @azuev-java Any other comments on this? Can you please look at the > CSR also? I have no additional comments. - PR: https://git.openjdk.java.net/jdk/pull/2874
Re: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v3]
On Wed, 7 Apr 2021 06:39:48 GMT, Andrey Turbanov
wrote:
>> There are few possible cleanups in java.desktop related to legacy
>> StringBuffer usages:
>> 1. In few places StringBuffer can be replaced with plain String
>> concatenation.
>> 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better
>> performance as it is not thread-safe.
>> 3. There are few places where result of string concatenation is passed to
>> StringBuffer.append method. Using separate `.append` calls is more clear.
>> 4. In few places primitives are unnecessary converted to String before
>> `.append` call. They can be replaced with specialized methods (like
>> `.append(int)` calls.
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop
>
> fix copyright year
Marked as reviewed by aivanov (Reviewer).
src/java.desktop/unix/classes/sun/awt/X11/XCreateWindowParams.java line 88:
> 86: while (eIter.hasNext()) {
> 87: Map.Entry entry = eIter.next();
> 88: buf.append(entry.getKey()).append(":
> ").append(entry.getValue()).append("\n");
Would it be clearer if each append was on its own line?
Suggestion:
buf.append(entry.getKey())
.append(": ")
.append(entry.getValue())
.append("\n");
-
PR: https://git.openjdk.java.net/jdk/pull/3251
Integrated: 8255800: Raster creation methods need some specification clean up
On Fri, 26 Mar 2021 19:53:44 GMT, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8255800 could have been a one line > spec clean up but > it didn't take a lot of looking to realize there were many more > inconsistencies between spec and implementation. > I've spent a lot of time on what is just small number of factory methods in > Raster because there are so > many possible exceptions and in some cases they rely on other API they call > to generate exceptions and > these may have not been documented or documented acc. to some long lost > behavior. > I've mostly tried to ONLY change spec. But I couldn't help myself when some > checks were missed that > ended up with bizarre and dubious behavior - throwing > NegativeArrayIndexException which just about > always has to be an internal bug ! > > The supplied test passes on JDK 16 as well as this code, because the > (relatively) small number of > cases where JDK 16 threw NegativeArrayIndexException are caught and allowed > only for releases < 17 > So where you see those in the test it corresponds to the behavioral changes > from NegativeArrayIndexException > to IllegalArgumentException. > JCK conformance tests still pass so they must not test those conditions. This pull request has now been integrated. Changeset: adb860ec Author:Phil Race URL: https://git.openjdk.java.net/jdk/commit/adb860ec Stats: 1494 lines in 5 files changed: 1424 ins; 35 del; 35 mod 8255800: Raster creation methods need some specification clean up Reviewed-by: serb - PR: https://git.openjdk.java.net/jdk/pull/3223
Re: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v3]
On Wed, 7 Apr 2021 06:39:48 GMT, Andrey Turbanov wrote: >> There are few possible cleanups in java.desktop related to legacy >> StringBuffer usages: >> 1. In few places StringBuffer can be replaced with plain String >> concatenation. >> 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better >> performance as it is not thread-safe. >> 3. There are few places where result of string concatenation is passed to >> StringBuffer.append method. Using separate `.append` calls is more clear. >> 4. In few places primitives are unnecessary converted to String before >> `.append` call. They can be replaced with specialized methods (like >> `.append(int)` calls. > > Andrey Turbanov has updated the pull request incrementally with one > additional commit since the last revision: > > [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop > > fix copyright year Marked as reviewed by azvegint (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3251
Re: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v3]
On Tue, 30 Mar 2021 15:46:56 GMT, Alexander Zvegintsev
wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop
>>
>> fix copyright year
>
> src/java.desktop/windows/classes/sun/java2d/d3d/D3DContext.java line 139:
>
>> 137: @Override
>> 138: public String toString() {
>> 139: StringBuilder buf = new StringBuilder(super.toString());
>
> Looks like this is the only file where copyright year is not updated.
Thanks. Fixed.
-
PR: https://git.openjdk.java.net/jdk/pull/3251
Re: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v3]
> There are few possible cleanups in java.desktop related to legacy > StringBuffer usages: > 1. In few places StringBuffer can be replaced with plain String concatenation. > 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better > performance as it is not thread-safe. > 3. There are few places where result of string concatenation is passed to > StringBuffer.append method. Using separate `.append` calls is more clear. > 4. In few places primitives are unnecessary converted to String before > `.append` call. They can be replaced with specialized methods (like > `.append(int)` calls. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop fix copyright year - Changes: - all: https://git.openjdk.java.net/jdk/pull/3251/files - new: https://git.openjdk.java.net/jdk/pull/3251/files/80bff1db..963dc56e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3251=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3251=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3251.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3251/head:pull/3251 PR: https://git.openjdk.java.net/jdk/pull/3251
Integrated: 8264680: Use the blessed modifier order in java.desktop
On Sat, 3 Apr 2021 22:03:44 GMT, Alex Blewitt wrote: > 8264680: Use the blessed modifier order in java.desktop This pull request has now been integrated. Changeset: 92fad1b4 Author:Alex Blewitt Committer: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/92fad1b4 Stats: 132 lines in 11 files changed: 0 ins; 114 del; 18 mod 8264680: Use the blessed modifier order in java.desktop Reviewed-by: serb, kizune, azvegint - PR: https://git.openjdk.java.net/jdk/pull/3337
