[OpenJDK 2D-Dev] RFR: 8264318 Lanai: DrawHugeImageTest.java fails on apple M1
Check if blit sizes are less than MTL_GPU_FAMILY_MAC_TXT_SIZE.
It's safe since we copy tile from the image with memcpy.
// copy src pixels inside src bounds to buff
for (int row = 0; row < sh; row++) {
memcpy(buff.contents + (row * sw * srcInfo->pixelStride), raster, sw *
srcInfo->pixelStride);
raster += (NSUInteger)srcInfo->scanStride;
}
-
Commit messages:
- 8264318: DrawHugeImageTest.java fails on apple M1
Changes: https://git.openjdk.java.net/jdk/pull/3369/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3369=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8264318
Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
Patch: https://git.openjdk.java.net/jdk/pull/3369.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/3369/head:pull/3369
PR: https://git.openjdk.java.net/jdk/pull/3369
[OpenJDK 2D-Dev] RFR: 8264143 Lanai: RenderPerfTest.BgrSwBlitImage has artefacts on apple M1
There was no code to check num of work items in compute shader. Also, I've replaced four similar shaders. - Commit messages: - 8264143: Lanai: RenderPerfTest.BgrSwBlitImage has artefacts on apple M1 Changes: https://git.openjdk.java.net/jdk/pull/3368/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3368=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264143 Stats: 73 lines in 3 files changed: 29 ins; 26 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/3368.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3368/head:pull/3368 PR: https://git.openjdk.java.net/jdk/pull/3368
Re: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v3]
On Tue, 6 Apr 2021 20:39:04 GMT, Alexey Ivanov wrote: >> I added a blank line between the condition and the body. >> Does it look good? @mrserb, @jayathirthrao > > [Code Conventions for > Java](https://www.oracle.com/java/technologies/javase/codeconventions-indentation.html#248) > say, “Line wrapping for `if` statements should generally use the 8-space > rule, since conventional (4 space) indentation makes seeing the body > difficult.” (It's the second to last block on the page.) If we are adding a new line, then I think we should need to add at l129, l138 otherwise it will look odd doing it at one place only. - PR: https://git.openjdk.java.net/jdk/pull/3151
Re: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v3]
On Tue, 6 Apr 2021 20:38:57 GMT, Alexey Ivanov wrote: >> When `getAllPrinterNames()` returns null, the list of `printServices` is >> assigned a new empty array without invalidating old services which were in >> the array before. >> >> The old print services should be invalidated. > > Alexey Ivanov has updated the pull request incrementally with one additional > commit since the last revision: > > Add a blank line to separate condition from body Marked as reviewed by jdv (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3151
Re: [OpenJDK 2D-Dev] RFR: 8263583: Emoji rendering on macOS
On Fri, 19 Mar 2021 16:46:32 GMT, Alexey Ushakov wrote: >> Implementation for Metal pipeline has been added. >> >> I've also updated the test case to check rendering into different types of >> images, including VolatileImage. The test will fail now, if corresponding >> OpenGL (or Metal, if it's explicitly enabled) implementation part would be >> rolled back. > > Looks good! It looks fine to me. I will run the tests in CI just in case. - PR: https://git.openjdk.java.net/jdk/pull/3007
Re: [OpenJDK 2D-Dev] RFR: 8263363: Minor cleanup of Lanai code - unused code removal and comments correction
On Tue, 6 Apr 2021 14:12:55 GMT, Ajit Ghaisas wrote:
> Refer JBS for 3 issues that this PR addresses.
> In addition, I have corrected an erroneous free() call in the same method I
> was cleaning up.
src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line
149:
> 147: try {
> 148: // getMTLConfigInfo() creates new MTLContext, so we should
> first
> 149: // invalidate the current Java-level context and flush the
> queue...
The old discussion was related not only to the comment but to the
invalidateCurrentContext, do we need to do it?
src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m
line 152:
> 150: NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
> 151:
> 152:
Please also check how this function is called, looks like previously it was
called as a selector+an array as a parameter, and then reworked as a
performOnMainThreadWaiting+block, but it still use an array as a parameter. I
think it is similar to JDK-8238075.
-
PR: https://git.openjdk.java.net/jdk/pull/3357
Re: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v3]
On Tue, 6 Apr 2021 20:38:57 GMT, Alexey Ivanov wrote: >> When `getAllPrinterNames()` returns null, the list of `printServices` is >> assigned a new empty array without invalidating old services which were in >> the array before. >> >> The old print services should be invalidated. > > Alexey Ivanov has updated the pull request incrementally with one additional > commit since the last revision: > > Add a blank line to separate condition from body Marked as reviewed by serb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3151
Re: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need some specification clean up [v3]
On Fri, 2 Apr 2021 22:40:53 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. > > Phil Race has updated the pull request incrementally with one additional > commit since the last revision: > > 8255800: Raster creation methods need some specification clean up Marked as reviewed by serb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3223
Re: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] [v3]
On Mon, 5 Apr 2021 10:34:21 GMT, Alexey Ushakov wrote:
>>> Can you check that it will work in the "new" tabbed mode on big sur as well?
>>
>> Could you suggest any working test scenario? My simple test (below) just
>> hangs even with OGL:
>>
>> import java.awt.FlowLayout;
>> import java.util.Objects;
>> import javax.swing.*;
>> import javax.swing.border.EmptyBorder;
>>
>> public class TestWindowInsets
>> extends JDialog
>> {
>>
>> public TestWindowInsets()
>> {
>> JComponent contentPane = (JComponent) getContentPane();
>> contentPane.setBorder(new EmptyBorder(50, 50, 50, 50));
>> JButton b = new JButton("Test");
>> b.addActionListener(e -> toggle());
>> add(b);
>> JButton c = new JButton("Win");
>> c.addActionListener(e -> win());
>> add(c);
>>
>> setLayout(new FlowLayout());
>> setSize(800, 600);
>>
>> setVisible(true);
>>
>> }
>>
>> void toggle()
>> {
>> SwingUtilities.invokeLater(() -> {
>> JRootPane rp = getRootPane();
>> String name = "apple.awt.fullWindowContent";
>> Object value = rp.getClientProperty(name);
>> if (Objects.equals(value, "true")) {
>> value = "false";
>> } else {
>> value = "true";
>> }
>> rp.putClientProperty(name, value);
>> });
>> }
>>
>> void win()
>> {
>> SwingUtilities.invokeLater(TestWindowInsets::new);
>> }
>>
>> public static void main(String[] args)
>> {
>> SwingUtilities.invokeLater(TestWindowInsets::new);
>> }
>> }
>
>> Probably it is possible to swap coordinates during rendering in the layer
>> and get rid of this field?
>
> I don't see a way how we can do it. Because of the inverted y coordinate in
> metal, we need to place the origin of the drawing with the appropriate offset
> that depends on the title height, even if we invert the y coordinate to match
> java2d coordinate system.
I am just not sure that this is the only place where the insets might be
changed.
We need to add a "callback" which will be called every time the insets will be
changed. Probably in the MTLLayer.replaceSurfaceData which should be called
from the LWWindowsPeer#notifyReshape->replaceSurfaceData(). Currently, we skip
that call if insets were changed. and this is why this bug arise.
-
PR: https://git.openjdk.java.net/jdk/pull/3308
Re: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v3]
On Tue, 6 Apr 2021 20:35:09 GMT, Alexey Ivanov wrote:
>> BTW another solution is to move { to the next line if the previous statement
>> was split across few lines.
>
> I added a blank line between the condition and the body.
> Does it look good? @mrserb, @jayathirthrao
[Code Conventions for
Java](https://www.oracle.com/java/technologies/javase/codeconventions-indentation.html#248)
say, “Line wrapping for `if` statements should generally use the 8-space rule,
since conventional (4 space) indentation makes seeing the body difficult.”
(It's the second to last block on the page.)
-
PR: https://git.openjdk.java.net/jdk/pull/3151
Re: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v3]
On Fri, 2 Apr 2021 01:56:37 GMT, Sergey Bylokhov wrote:
>>> To make it clear, you're for keeping the indentation as it was in the
>>> original PR to visually separate condition from the statement in the if
>>> block. Do I get it right, @mrserb?
>>
>> I think it looks better.
>
> BTW another solution is to move { to the next line if the previous statement
> was split across few lines.
I added a blank line between the condition and the body.
Does it look good? @mrserb, @jayathirthrao
-
PR: https://git.openjdk.java.net/jdk/pull/3151
Re: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v3]
> When `getAllPrinterNames()` returns null, the list of `printServices` is > assigned a new empty array without invalidating old services which were in > the array before. > > The old print services should be invalidated. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: Add a blank line to separate condition from body - Changes: - all: https://git.openjdk.java.net/jdk/pull/3151/files - new: https://git.openjdk.java.net/jdk/pull/3151/files/edc8ab06..774e4074 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3151=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3151=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3151/head:pull/3151 PR: https://git.openjdk.java.net/jdk/pull/3151
Re: [OpenJDK 2D-Dev] RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v2]
On Tue, 30 Mar 2021 19:05:37 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
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.
-
PR: https://git.openjdk.java.net/jdk/pull/3251
Re: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai]
On Tue, 6 Apr 2021 12:51:47 GMT, Alexey Ushakov wrote: > > @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 " - PR: https://git.openjdk.java.net/jdk/pull/3308
Re: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai]
On Tue, 6 Apr 2021 12:03:14 GMT, Jayathirth D V wrote: > > > Is it possible to automatically test it? > > > > > > Yes, just added the test. > > @avu Test passes without fix also. @aghaisas Please verify the regression test behavior from your end also. - PR: https://git.openjdk.java.net/jdk/pull/3308
[OpenJDK 2D-Dev] RFR: 8263363: Minor cleanup of Lanai code - unused code removal and comments correction
Refer JBS for 3 issues that this PR addresses. In addition, I have corrected an erroneous free() call in the same method I was cleaning up. - Commit messages: - 8263363 - cleanup Changes: https://git.openjdk.java.net/jdk/pull/3357/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3357=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263363 Stats: 21 lines in 3 files changed: 1 ins; 16 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3357.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3357/head:pull/3357 PR: https://git.openjdk.java.net/jdk/pull/3357
Re: [OpenJDK 2D-Dev] RFR: 8264680: Use the blessed modifier order in java.desktop [v2]
On Sat, 3 Apr 2021 22:28:54 GMT, Alex Blewitt wrote: >> 8264680: Use the blessed modifier order in java.desktop > > Alex Blewitt has updated the pull request incrementally with one additional > commit since the last revision: > > Additionally remove detritus from PNGImageDecoder.java Marked as reviewed by azvegint (Reviewer). src/java.desktop/share/classes/sun/awt/image/PNGImageDecoder.java line 2: > 1: /* > 2: * Copyright (c) 1999, 2021, Oracle and/or its affiliates. All rights > reserved. Copyright year in other files might be updated as well. - PR: https://git.openjdk.java.net/jdk/pull/3337
Re: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai]
On Fri, 2 Apr 2021 11:41:12 GMT, Alexey Ushakov wrote: >> Is it possible to automatically test it? > >> 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 ? - PR: https://git.openjdk.java.net/jdk/pull/3308
Re: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai]
On Fri, 2 Apr 2021 11:41:12 GMT, Alexey Ushakov wrote: > > Is it possible to automatically test it? > > Yes, just added the test. @avu Test passes without fix also. - PR: https://git.openjdk.java.net/jdk/pull/3308
Re: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai]
On Tue, 6 Apr 2021 12:03:14 GMT, Jayathirth D V wrote: >>> Is it possible to automatically test it? >> >> Yes, just added the test. > >> > Is it possible to automatically test it? >> >> Yes, just added the test. > > @avu Test passes without fix also. Verified test case attached in JBS : https://bugs.openjdk.java.net/browse/JDK-8258788 . I see that fix resolves identified issue in JBS. Also jtreg and JCK test run is green with and without Metal API validation flags. - PR: https://git.openjdk.java.net/jdk/pull/3308
[OpenJDK 2D-Dev] Integrated: 8264047: Duplicate global variable 'jvm' in libjavajpeg and libawt
On Tue, 23 Mar 2021 15:18:13 GMT, Severin Gehwolf wrote: > The suggestion is to rename 'jvm' variable in `libjavajpeg` to `the_jvm` so > this conflict no longer occurs when `libjavajpeg.a` and `libawt.a` are being > linked into one native image. > > Testing: test/jdk/javax/imageio jtreg tests. GHA pre-integration tests > running too. > > Thoughts? This pull request has now been integrated. Changeset: eb6330e4 Author:Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/eb6330e4 Stats: 14 lines in 2 files changed: 0 ins; 0 del; 14 mod 8264047: Duplicate global variable 'jvm' in libjavajpeg and libawt Reviewed-by: serb - PR: https://git.openjdk.java.net/jdk/pull/3155
Re: [OpenJDK 2D-Dev] RFR: 8264047: Duplicate global variable 'jvm' in libjavajpeg and libawt
On Wed, 31 Mar 2021 20:37:32 GMT, Sergey Bylokhov wrote: >> The suggestion is to rename 'jvm' variable in `libjavajpeg` to `the_jvm` so >> this conflict no longer occurs when `libjavajpeg.a` and `libawt.a` are being >> linked into one native image. >> >> Testing: test/jdk/javax/imageio jtreg tests. GHA pre-integration tests >> running too. >> >> Thoughts? > > Marked as reviewed by serb (Reviewer). @mrserb Thanks for the review! - PR: https://git.openjdk.java.net/jdk/pull/3155
