Re: RFR: 8339508: RenderPerf Test Application [v2]
On Wed, 18 Sep 2024 15:25:47 GMT, Lukasz Kostyra wrote: >> This PR migrates RenderPerf performance test application from jfx-sandbox >> metal branch: >> https://github.com/openjdk/jfx-sandbox/tree/metal/tests/performance/animation/RenderPerfTest/src/renderperf >> >> RenderPerf is a performance test application which draws provided number of >> "particles" (JFX nodes) on the screen and animates them. After some time >> (default 10 seconds of testing + warmup) the test automatically closes and >> reports FPS values. Test was developed as part of Metal backend for >> performance testing and we decided to integrate it with mainline for any >> potential further development and fixes. >> >> Command line options for the test: >> - `-n` - number of particles to draw, defaults to 1000 >> - `-t` - name of test to run, defaults to running all tests in random order. >> Can provide multiple tests, ex. `-t Rectangle Image` >> - `-d` - test duration in seconds, defaults to 10. Can be set to 0, which >> means the test will run infinitely long and end only when user manually >> closes the stage, mostly useful for stability testing. >> >> Some tests use `duke.png` image provided with this PR. This is an openly >> available Duke Wave image taken from >> https://wiki.openjdk.org/display/duke/Gallery and rescaled for test purposes. >> >> PR consists of two commits: >> - Base version of RenderPerfTest developed by @karthikpandelu >> - My commit adding `-d` flag and implementing plenty of other fixes as part >> of [JDK-8331570](https://bugs.openjdk.org/browse/JDK-8331570) > > Lukasz Kostyra has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright year to 2024 I did basic testing with different options and everything works fine. Its good that we are open-sourcing this rendering performance test. LGTM. - Marked as reviewed by jdv (Author). PR Review: https://git.openjdk.org/jfx/pull/1568#pullrequestreview-2315194679
Integrated: 8211234: Open-source simple test programs for FX / Swing interop
On Tue, 17 Sep 2024 15:33:06 GMT, Jayathirth D V wrote: > This PR is for open-sourcing 2 closed toys EmbeddedSwing and HelloWorld. > JBS : https://bugs.openjdk.org/browse/JDK-8211234 > > 1)EmbeddedSwing - a simple FX test app with a SwingNode containing a Swing > application > > 2)HelloWorld contains 2 test apps : > > - HelloJFXPanel - a simple Swing test app with a JButton and a JFXPanel > containing an animated rectangle > > - HelloJFXPanel2 - a simple Swing test app with a JButton and a JFXPanel > containing a JavaFX Button and ComboBox (with Tooltips) > > These new test apps are added under apps/toys/ directory. This pull request has now been integrated. Changeset: 6d1dd293 Author:Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/6d1dd293d690f34dc87e86edc6ec2490f6d48967 Stats: 1293 lines in 18 files changed: 1272 ins; 2 del; 19 mod 8211234: Open-source simple test programs for FX / Swing interop Reviewed-by: kcr - PR: https://git.openjdk.org/jfx/pull/1572
Re: RFR: 8211234: Open-source simple test programs for FX / Swing interop
On Wed, 18 Sep 2024 14:00:24 GMT, Kevin Rushforth wrote: > Ah, never mind. I see that you already resolved the conflict. I'll re-review > then. Yes Kevin, i was pushing the changes one after another because i was also suspecting merge conflict in apps/toys/build.xml - PR Comment: https://git.openjdk.org/jfx/pull/1572#issuecomment-2358559533
Re: RFR: 8211234: Open-source simple test programs for FX / Swing interop [v2]
> This PR is for open-sourcing 2 closed toys EmbeddedSwing and HelloWorld. > JBS : https://bugs.openjdk.org/browse/JDK-8211234 > > 1)EmbeddedSwing - a simple FX test app with a SwingNode containing a Swing > application > > 2)HelloWorld contains 2 test apps : > > - HelloJFXPanel - a simple Swing test app with a JButton and a JFXPanel > containing an animated rectangle > > - HelloJFXPanel2 - a simple Swing test app with a JButton and a JFXPanel > containing a JavaFX Button and ComboBox (with Tooltips) > > These new test apps are added under apps/toys/ directory. Jayathirth D V has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Resolve conflicts using latest upstream change - 8211234: Open-source simple test programs for FX / Swing interop - Changes: https://git.openjdk.org/jfx/pull/1572/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1572&range=01 Stats: 1293 lines in 18 files changed: 1272 ins; 2 del; 19 mod Patch: https://git.openjdk.org/jfx/pull/1572.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1572/head:pull/1572 PR: https://git.openjdk.org/jfx/pull/1572
Integrated: 8211247: Open-source simple test programs for FX / SWT interop
On Tue, 17 Sep 2024 14:29:11 GMT, Jayathirth D V wrote: > This PR is for open-sourcing HelloFXCanvas test app. > JBS : https://bugs.openjdk.org/browse/JDK-8211247 > It is an SWT app with SWT button and an FXCanvas with animated rectangle. > This is used on our integration testing. > > This test is now moved to apps/toys, please refer to > apps/toys/HelloFXCanvas/README.txt on how to run this toy. > > Also this toy hangs on exit in macOS and it crashes on Wayland in Ubuntu > 24.04, for which separate bugs will be raised. This pull request has now been integrated. Changeset: f8a20056 Author:Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/f8a20056f4b19b45d311b96126b0a5fcfbe96923 Stats: 1266 lines in 9 files changed: 1263 ins; 0 del; 3 mod 8211247: Open-source simple test programs for FX / SWT interop Reviewed-by: kcr - PR: https://git.openjdk.org/jfx/pull/1571
RFR: 8211234: Open-source simple test programs for FX / Swing interop
This PR is for open-sourcing 2 closed toys EmbeddedSwing and HelloWorld. JBS : https://bugs.openjdk.org/browse/JDK-8211234 1)EmbeddedSwing - a simple FX test app with a SwingNode containing a Swing application 2)HelloWorld contains 2 test apps : - HelloJFXPanel - a simple Swing test app with a JButton and a JFXPanel containing an animated rectangle - HelloJFXPanel2 - a simple Swing test app with a JButton and a JFXPanel containing a JavaFX Button and ComboBox (with Tooltips) These new test apps are added under apps/toys/ directory. - Commit messages: - 8211234: Open-source simple test programs for FX / Swing interop Changes: https://git.openjdk.org/jfx/pull/1572/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1572&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8211234 Stats: 3379 lines in 18 files changed: 3373 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1572.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1572/head:pull/1572 PR: https://git.openjdk.org/jfx/pull/1572
RFR: 8211247: Open-source simple test programs for FX / SWT interop
This PR is for open-sourcing HelloFXCanvas test app. JBS : https://bugs.openjdk.org/browse/JDK-8211247 It is an SWT app with SWT button and an FXCanvas with animated rectangle. This is used on our integration testing. This test is now moved to apps/toys, please refer to apps/toys/HelloFXCanvas/README.txt on how to run this toy. Also this toy hangs on exit in macOS and it crashes on Wayland in Ubuntu 24.04, for which separate bugs will be raised. - Commit messages: - 8211247: Open-source simple test programs for FX / SWT interop Changes: https://git.openjdk.org/jfx/pull/1571/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1571&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8211247 Stats: 1266 lines in 9 files changed: 1263 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1571.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1571/head:pull/1571 PR: https://git.openjdk.org/jfx/pull/1571
Integrated: 8332863: Crash in JPEG decoder if we enable MEM_STATS
On Fri, 24 May 2024 06:48:50 GMT, Jayathirth D V wrote: > In IJG library's jmemmgr.c file we can define MEM_STATS(by default this flag > is not defined and we don't see any issue) to enable printing of memory > statistics log. But if we enable it, we get crash while disposing IJG stored > objects in jmemmgr->free-pool() function. > > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0001269d5164, pid=47784, tid=259 > # > # JRE version: Java(TM) SE Runtime Environment (21.0+35) (build > 21+35-LTS-2513) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (21+35-LTS-2513, mixed mode, > sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64) > # Problematic frame: > # C [libjavafx_iio.dylib+0x49164] free_pool+0x88 > # > # No core dump will be written. Core dumps have been disabled. To enable core > dumping, try "ulimit -c unlimited" before starting Java again > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > > --- T H R E A D --- > > Current thread (0x000121a42c00): JavaThread "JavaFX Application Thread" > [_thread_in_native, id=259, stack(0x00016d11c000,0x00016d918000) > (8176K)] > > Stack: [0x00016d11c000,0x00016d918000], sp=0x00016d912780, free > space=8153k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > C [libjavafx_iio.dylib+0x49164] free_pool+0x88 > C [libjavafx_iio.dylib+0x49410] self_destruct+0x3c > C [libjavafx_iio.dylib+0xe888] jpeg_destroy+0x3c > C [libjavafx_iio.dylib+0x4bb1c] imageio_dispose+0x98 > C [libjavafx_iio.dylib+0x4b178] disposeIIO+0x2c > C [libjavafx_iio.dylib+0x4b140] > Java_com_sun_javafx_iio_jpeg_JPEGImageLoader_disposeNative+0x2c > > > This is happening because we delete the error handler before we actually > start deleting IJG stored objects and while freeing the IJG objects we try to > access cinfo->err->trace_level of error handler. This early deletion of error > handler is happening in jpegloader.c->imageio_dispose() function. > > I have moved deletion of error handler logic after we destroy IJG stored > objects in jpegloader.c->imageio_dispose(). This resolves this issue. > There is no regression test case because we need to enable MEM_STATS flag to > see this issue. > Ran graphics unit tests also and i don't see any issues with this change. This pull request has now been integrated. Changeset: cf09d6f1 Author:Jayathirth D V Committer: Michael Strauß URL: https://git.openjdk.org/jfx/commit/cf09d6f1b8e479e77683c91e271fac8716fe0791 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod 8332863: Crash in JPEG decoder if we enable MEM_STATS Reviewed-by: mstrauss, aghaisas - PR: https://git.openjdk.org/jfx/pull/1463
RFR: 8332863: Crash in JPEG decoder if we enable MEM_STATS
In IJG library's jmemmgr.c file we can define MEM_STATS(by default this flag is not defined and we don't see any issue) to enable printing of memory statistics log. But if we enable it, we get crash while disposing IJG stored objects in jmemmgr->free-pool() function. # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0001269d5164, pid=47784, tid=259 # # JRE version: Java(TM) SE Runtime Environment (21.0+35) (build 21+35-LTS-2513) # Java VM: Java HotSpot(TM) 64-Bit Server VM (21+35-LTS-2513, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64) # Problematic frame: # C [libjavafx_iio.dylib+0x49164] free_pool+0x88 # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. --- T H R E A D --- Current thread (0x000121a42c00): JavaThread "JavaFX Application Thread" [_thread_in_native, id=259, stack(0x00016d11c000,0x00016d918000) (8176K)] Stack: [0x00016d11c000,0x00016d918000], sp=0x00016d912780, free space=8153k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libjavafx_iio.dylib+0x49164] free_pool+0x88 C [libjavafx_iio.dylib+0x49410] self_destruct+0x3c C [libjavafx_iio.dylib+0xe888] jpeg_destroy+0x3c C [libjavafx_iio.dylib+0x4bb1c] imageio_dispose+0x98 C [libjavafx_iio.dylib+0x4b178] disposeIIO+0x2c C [libjavafx_iio.dylib+0x4b140] Java_com_sun_javafx_iio_jpeg_JPEGImageLoader_disposeNative+0x2c This is happening because we delete the error handler before we actually start deleting IJG stored objects and while freeing the IJG objects we try to access cinfo->err->trace_level of error handler. This early deletion of error handler is happening in jpegloader.c->imageio_dispose() function. I have moved deletion of error handler logic after we destroy IJG stored objects in jpegloader.c->imageio_dispose(). This resolves this issue. There is no regression test case because we need to enable MEM_STATS flag to see this issue. Ran graphics unit tests also and i don't see any issues with this change. - Commit messages: - 8332863: Crash in JPEG decoder if we enable MEM_STATS Changes: https://git.openjdk.org/jfx/pull/1463/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1463&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332863 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1463.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1463/head:pull/1463 PR: https://git.openjdk.org/jfx/pull/1463
Integrated: 8306322: JDK8130122Test fails intermittently
On Mon, 25 Mar 2024 12:25:33 GMT, Jayathirth D V wrote: > This test has failed once and we are not seeing its failure after that > instance in our test systems. > > This test verifies whether bounds of GridPane gets updated properly on adding > an invisible node. > Initial test has 8 nodes in GridPane and then we update it with another node > with larger bounds without making it visible. After adding additional node we > make the scenegraph visible and check for colors of the newly added node. > > We are making this test robust to make sure we don't see any of these single > instance failures. > Test is updated to: > 1) To always show on top, so that we pick proper color. > 2) Add additional sleep so that we give more time for test to be visible. > 3) Pick color exactly at mid point in y axis, so that we pick the green color > properly. This pull request has now been integrated. Changeset: 0541f371 Author:Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/0541f37179ff4a672a40f3c4976e6019b8ecf7c2 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8306322: JDK8130122Test fails intermittently Reviewed-by: kcr, angorya - PR: https://git.openjdk.org/jfx/pull/1433
Re: RFR: 8306322: JDK8130122Test fails intermittently [v2]
> This test has failed once and we are not seeing its failure after that > instance in our test systems. > > This test verifies whether bounds of GridPane gets updated properly on adding > an invisible node. > Initial test has 8 nodes in GridPane and then we update it with another node > with larger bounds without making it visible. After adding additional node we > make the scenegraph visible and check for colors of the newly added node. > > We are making this test robust to make sure we don't see any of these single > instance failures. > Test is updated to: > 1) To always show on top, so that we pick proper color. > 2) Add additional sleep so that we give more time for test to be visible. > 3) Pick color exactly at mid point in y axis, so that we pick the green color > properly. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Remove setAlwaysOnTop and update wait call - Changes: - all: https://git.openjdk.org/jfx/pull/1433/files - new: https://git.openjdk.org/jfx/pull/1433/files/2c9ed7d9..c4f3b9c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1433&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1433&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1433.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1433/head:pull/1433 PR: https://git.openjdk.org/jfx/pull/1433
Re: RFR: 8306322: JDK8130122Test fails intermittently
On Mon, 25 Mar 2024 16:40:56 GMT, Andy Goryachev wrote:
>> This test has failed once and we are not seeing its failure after that
>> instance in our test systems.
>>
>> This test verifies whether bounds of GridPane gets updated properly on
>> adding an invisible node.
>> Initial test has 8 nodes in GridPane and then we update it with another node
>> with larger bounds without making it visible. After adding additional node
>> we make the scenegraph visible and check for colors of the newly added node.
>>
>> We are making this test robust to make sure we don't see any of these single
>> instance failures.
>> Test is updated to:
>> 1) To always show on top, so that we pick proper color.
>> 2) Add additional sleep so that we give more time for test to be visible.
>> 3) Pick color exactly at mid point in y axis, so that we pick the green
>> color properly.
>
> tests/system/src/test/java/test/robot/scenegraph/JDK8130122Test.java line 102:
>
>> 100: horizontalListView.setVisible(true);
>> 101: });
>> 102: sleep(1000);
>
> we still have JDK-8176902 open, but perhaps here we could add a new method to
> VisualTestBase similar to waitNextFrame(), with an appropriate parameter?
>
> Something like
>
> protected void waitForIdle() {
> frameWait(100);
> }
>
>
> instead of 1 second sleep() ? What do you think?
I think waitForIdle() would not be a proper name for this use case.
And we already have waitFirstFrame() which does frameWait(100).
What i will do is, use waitFirstFrame() and add comment in test case that we
are waiting after setVisible(true).
-
PR Review Comment: https://git.openjdk.org/jfx/pull/1433#discussion_r1538649261
Re: RFR: 8306322: JDK8130122Test fails intermittently
On Mon, 25 Mar 2024 14:26:10 GMT, Kevin Rushforth wrote: >> This test has failed once and we are not seeing its failure after that >> instance in our test systems. >> >> This test verifies whether bounds of GridPane gets updated properly on >> adding an invisible node. >> Initial test has 8 nodes in GridPane and then we update it with another node >> with larger bounds without making it visible. After adding additional node >> we make the scenegraph visible and check for colors of the newly added node. >> >> We are making this test robust to make sure we don't see any of these single >> instance failures. >> Test is updated to: >> 1) To always show on top, so that we pick proper color. >> 2) Add additional sleep so that we give more time for test to be visible. >> 3) Pick color exactly at mid point in y axis, so that we pick the green >> color properly. > > tests/system/src/test/java/test/robot/scenegraph/JDK8130122Test.java line 87: > >> 85: testScene.setFill(Color.WHITE); >> 86: testStage.setScene(testScene); >> 87: testStage.setAlwaysOnTop(true); > > This is redundant. `getStage()` already sets `alwaysOnTop`. If the window > currently isn't always on top then we have a bigger problem. I see that thanks, i didn't notice it. I will remove the change. I took https://github.com/openjdk/jfx/commit/56f2e17f#diff-43fd8d27727f352ddb3526031bd32e5d30aefa2bad722d1f3d21c4a0ca8a5a1f as an example and made this change. - PR Review Comment: https://git.openjdk.org/jfx/pull/1433#discussion_r1538643028
Re: RFR: 8327179: Update the 3D lighting application [v4]
On Wed, 13 Mar 2024 22:32:59 GMT, Nir Lisker wrote: >> Update for the 3D lighting test tool as described in the JBS issue. > > Nir Lisker has updated the pull request incrementally with five additional > commits since the last revision: > > - Added spacing > - Renamed constant > - Updated benchmark reset message > - Simplified models creation > - Revert resource package Even after reverting package name i continue to see that 3DLighting throws exception when we manually launch it: javafx.graphics@23-internal/javafx.scene.image.Image.validateInputStream(Image.java:1140) at javafx.graphics@23-internal/javafx.scene.image.Image.(Image.java:707) at attenuation.Environment.(Environment.java:64) - PR Comment: https://git.openjdk.org/jfx/pull/1387#issuecomment-2017939695
RFR: 8306322: JDK8130122Test fails intermittently
This test has failed once and we are not seeing its failure after that instance in our test systems. This test verifies whether bounds of GridPane gets updated properly on adding an invisible node. Initial test has 8 nodes in GridPane and then we update it with another node with larger bounds without making it visible. After adding additional node we make the scenegraph visible and check for colors of the newly added node. We are making this test robust to make sure we don't see any of these single instance failures. Test is updated to: 1) To always show on top, so that we pick proper color. 2) Add additional sleep so that we give more time for test to be visible. 3) Pick color exactly at mid point in y axis, so that we pick the green color properly. - Commit messages: - 8306322: JDK8130122Test fails intermittently Changes: https://git.openjdk.org/jfx/pull/1433/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1433&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306322 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1433.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1433/head:pull/1433 PR: https://git.openjdk.org/jfx/pull/1433
Integrated: 8255679: RegionBackgroundImageUITest.unalignedImage_Cover fails because of wrong color
On Wed, 13 Mar 2024 08:56:13 GMT, Jayathirth D V wrote: > Updated test to get screen capture in different platforms to see how we are > picking colors. Found that this test fails because it assumes that red,green > & blue bands in the test image are of equal size and picks color based on > that assumption. > > If we take 20 * 20 aligned image, each scanline is 3 red pixels -> 3 green > pixels -> 8 blue pixels -> 3 green pixels -> 3 red pixels. So the blue pixels > actually acquire more space in a scanline. Even in y direction pattern is > same. > > If we 48 * 48 unaligned image, each scanline is 7 red pixels -> 8 green > pixels -> 19 blue pixels -> 7 green pixels -> 7 red pixels. So the blue > pixels actually acquire more space in a scanline. Even in y direction pattern > is same. > > So when this 48 * 48 image is scaled to 336 * 336 in case of > unalignedImage_Cover, we are calculating picking point for green color in > such a way that it is hitting border of green and blue bands and test is > failing. Only in this specific scenario we are scaling by large amount and > the inappropriate color picking logic is failing. > > Updated color picking logic in such a way that appropriate weightage is given > to each color and we pick that color properly even when we have large > scaling. With this change test is passing on all platforms and there are no > regressions seen in all test run. This pull request has now been integrated. Changeset: c196454e Author:Jayathirth D V Committer: Ajit Ghaisas URL: https://git.openjdk.org/jfx/commit/c196454e76dec1cbcd028e12d99f052981a63a4e Stats: 7 lines in 1 file changed: 1 ins; 1 del; 5 mod 8255679: RegionBackgroundImageUITest.unalignedImage_Cover fails because of wrong color Reviewed-by: aghaisas - PR: https://git.openjdk.org/jfx/pull/1400
RFR: 8255679: RegionBackgroundImageUITest.unalignedImage_Cover fails because of wrong color
Updated test to get screen capture in different platforms to see how we are picking colors. Found that this test fails because it assumes that red,green & blue bands in the test image are of equal size and picks color based on that assumption. If we take 20 * 20 aligned image, each scanline is 3 red pixels -> 3 green pixels -> 8 blue pixels -> 3 green pixels -> 3 red pixels. So the blue pixels actually acquire more space in a scanline. Even in y direction pattern is same. If we 48 * 48 unaligned image, each scanline is 7 red pixels -> 8 green pixels -> 19 blue pixels -> 7 green pixels -> 7 red pixels. So the blue pixels actually acquire more space in a scanline. Even in y direction pattern is same. So when this 48 * 48 image is scaled to 336 * 336 in case of unalignedImage_Cover, we are calculating picking point for green color in such a way that it is hitting border of green and blue bands and test is failing. Only in this specific scenario we are scaling by large amount and the inappropriate color picking logic is failing. Updated color picking logic in such a way that appropriate weightage is given to each color and we pick that color properly even when we have large scaling. With this change test is passing on all platforms and there are no regressions seen in all test run. - Commit messages: - Initial change Changes: https://git.openjdk.org/jfx/pull/1400/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1400&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8255679 Stats: 7 lines in 1 file changed: 1 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1400.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1400/head:pull/1400 PR: https://git.openjdk.org/jfx/pull/1400
[jfx22u] Integrated: 8324233: Update JPEG Image Decoding Software to 9f
On Thu, 29 Feb 2024 16:09:47 GMT, Jayathirth D V wrote: > This is 22u backport for updating libjpeg version to 9f. > Original bug : https://bugs.openjdk.org/browse/JDK-8324233 This pull request has now been integrated. Changeset: e54102ca Author:Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx22u/commit/e54102cad7432dbef11d156947ae0e41bc530fd7 Stats: 463 lines in 28 files changed: 174 ins; 96 del; 193 mod 8324233: Update JPEG Image Decoding Software to 9f Backport-of: b99eb45828317e4c195b46eb0c9371d4645f2c6c - PR: https://git.openjdk.org/jfx22u/pull/15
[jfx22u] RFR: 8324233: Update JPEG Image Decoding Software to 9f
This is 22u backport for updating libjpeg version to 9f. Original bug : https://bugs.openjdk.org/browse/JDK-8324233 - Commit messages: - Backport b99eb45828317e4c195b46eb0c9371d4645f2c6c Changes: https://git.openjdk.org/jfx22u/pull/15/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=15&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324233 Stats: 463 lines in 28 files changed: 174 ins; 96 del; 193 mod Patch: https://git.openjdk.org/jfx22u/pull/15.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/15/head:pull/15 PR: https://git.openjdk.org/jfx22u/pull/15
Integrated: 8324233: Update JPEG Image Decoding Software to 9f
On Tue, 20 Feb 2024 05:50:19 GMT, Jayathirth D V wrote: > IJG has released latest version of libjpeg 9f and we need to update our > version also match 9f changes. > IJG reference : https://www.ijg.org/ > > With updated changes both headless and headful tests are green on all > platforms. > > Also while updating to 9f noticed that many files don't have latest copyright > year and comments from previous version updates like 9e, so updated that part > also to match 9f version. This pull request has now been integrated. Changeset: b99eb458 Author:Jayathirth D V Committer: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/b99eb45828317e4c195b46eb0c9371d4645f2c6c Stats: 463 lines in 28 files changed: 174 ins; 96 del; 193 mod 8324233: Update JPEG Image Decoding Software to 9f Reviewed-by: kcr, arapte - PR: https://git.openjdk.org/jfx/pull/1372
Re: RFR: 8324233: Update JPEG Image Decoding Software to 9f [v2]
On Thu, 29 Feb 2024 06:21:34 GMT, Ambarish Rapte wrote: >> Jayathirth D V has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update > > modules/javafx.graphics/src/main/native-iio/libjpeg/UPDATING.txt line 12: > >> 10: 3) OpenJFX imports only the JPEG library source with some exceptions. >> 11: OpenJFX does not need any other applications or tools provided by IJG >> libjpeg. >> 12: Copy only the same 49 .c and 9 .h files as are already there. > > I could see only _41_ _.c_ files in this directory: > `modules/javafx.graphics/src/main/native-iio/libjpeg` > Could you please recheck. Thanks for noticing it, i have updated the number of .c files back to 41 but changed .h files to 8. Because jconfig.h file is not part of upstream IJG. - PR Review Comment: https://git.openjdk.org/jfx/pull/1372#discussion_r1507267316
Re: RFR: 8324233: Update JPEG Image Decoding Software to 9f [v3]
> IJG has released latest version of libjpeg 9f and we need to update our > version also match 9f changes. > IJG reference : https://www.ijg.org/ > > With updated changes both headless and headful tests are green on all > platforms. > > Also while updating to 9f noticed that many files don't have latest copyright > year and comments from previous version updates like 9e, so updated that part > also to match 9f version. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Update proper number for files - Changes: - all: https://git.openjdk.org/jfx/pull/1372/files - new: https://git.openjdk.org/jfx/pull/1372/files/5df260c7..b43a51e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1372&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1372&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1372.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1372/head:pull/1372 PR: https://git.openjdk.org/jfx/pull/1372
Re: RFR: 8324233: Update JPEG Image Decoding Software to 9f [v2]
> IJG has released latest version of libjpeg 9f and we need to update our > version also match 9f changes. > IJG reference : https://www.ijg.org/ > > With updated changes both headless and headful tests are green on all > platforms. > > Also while updating to 9f noticed that many files don't have latest copyright > year and comments from previous version updates like 9e, so updated that part > also to match 9f version. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Update - Changes: - all: https://git.openjdk.org/jfx/pull/1372/files - new: https://git.openjdk.org/jfx/pull/1372/files/c3d40ab9..5df260c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1372&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1372&range=00-01 Stats: 13 lines in 1 file changed: 2 ins; 10 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1372.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1372/head:pull/1372 PR: https://git.openjdk.org/jfx/pull/1372
RFR: 8324233: Update JPEG Image Decoding Software to 9f
IJG has released latest version of libjpeg 9f and we need to update our version also match 9f changes. IJG reference : https://www.ijg.org/ With updated changes both headless and headful tests are green on all platforms. Also while updating to 9f noticed that many files don't have latest copyright year and comments from previous version updates like 9e, so updated that part also to match 9f version. - Commit messages: - jcheck errors - Whitespace errors - Initial change Changes: https://git.openjdk.org/jfx/pull/1372/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1372&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324233 Stats: 450 lines in 28 files changed: 171 ins; 86 del; 193 mod Patch: https://git.openjdk.org/jfx/pull/1372.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1372/head:pull/1372 PR: https://git.openjdk.org/jfx/pull/1372
[jfx21u] Integrated: 8319079: Missing range checks in decora
On Thu, 2 Nov 2023 16:26:57 GMT, Jayathirth D V wrote: > This is jfx21u backport of https://bugs.openjdk.org/browse/JDK-8319079 > It adds appropriate range checks in native code for Box/Gaussian Blur/Shadow > effects in Software pipeline. This pull request has now been integrated. Changeset: 5f21d465 Author:Jayathirth D V Committer: Ambarish Rapte URL: https://git.openjdk.org/jfx21u/commit/5f21d465507ab67eb056f9f34b2cd9523c43bc57 Stats: 85 lines in 6 files changed: 85 ins; 0 del; 0 mod 8319079: Missing range checks in decora Backport-of: 96e5d10a40dc25b999ff229f1d6601d1058761b2 - PR: https://git.openjdk.org/jfx21u/pull/25
[jfx-tests] Integrated: 8315896: Perspective lod tests fail because of minute difference in values
On Fri, 8 Sep 2023 07:07:40 GMT, Jayathirth D V wrote: > Two perspective lod tests fail because of minute differences in expected > values. > > Failing tests: > test/scenegraph/fx3d/lod/PerspectiveLodCameraTest.java: > test/scenegraph/fx3d/lod/PerspectiveLodGroupTest.java: > > Exception: > test test.scenegraph.fx3d.lod.LodTests.sphereInitialLightOnTest(): failure > org.jemmy.TimeoutExpiredException: State 'Expected 50180.140882730484, but > was 50180.137157440186' has not been reached in 1000 milliseconds > at org.jemmy.timing.Waiter.ensureValue(Waiter.java:93) > at test.scenegraph.fx3d.lod.LodTestBase.checkLod(LodTestBase.java:117) > at > test.scenegraph.fx3d.lod.LodTests.sphereInitialLightOnTest(LodTests.java:98) > at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:577) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299) > at > org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.lang.Thread.run(Thread.java:833) > > These little difference in values are seen both initial drawing and updates. > These tests are not run from long time and change in product might change lod > values. > > With updated lod values i have verified that both the tests pass in OpenGL > and Metal pipeline with both retina display(scale = 2) and external > monitor(scale = 1). This pull request has now been integrated. Changeset: e5f951c7 Author:Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx-tests/commit/e5f951c77a315c224710e47cba0ef8084e3a7d8d Stats: 10 lines in 3 files changed: 1 ins; 0 del; 9 mod 8315896: Perspective lod tests fail because of minute difference in values Reviewed-by: kcr - PR: https://git.openjdk.org/jfx-tests/pull/6
Re: [jfx-tests] RFR: 8315896: Perspective lod tests fail because of minute difference in values [v3]
On Thu, 2 Nov 2023 13:47:26 GMT, Kevin Rushforth wrote: > Looks good. Please file a follow-up bug to get the tests running on Windows. I have created follow-up issue https://bugs.openjdk.org/browse/JDK-8319329 for Windows. - PR Comment: https://git.openjdk.org/jfx-tests/pull/6#issuecomment-1791088077
[jfx21u] RFR: 8319079: Missing range checks in decora
This is jfx21u backport of https://bugs.openjdk.org/browse/JDK-8319079 It adds appropriate range checks in native code for Box/Gaussian Blur/Shadow effects in Software pipeline. - Commit messages: - Backport 96e5d10a40dc25b999ff229f1d6601d1058761b2 Changes: https://git.openjdk.org/jfx21u/pull/25/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=25&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319079 Stats: 85 lines in 6 files changed: 85 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx21u/pull/25.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/25/head:pull/25 PR: https://git.openjdk.org/jfx21u/pull/25
Integrated: 8319079: Missing range checks in decora
On Mon, 30 Oct 2023 06:55:11 GMT, Jayathirth D V wrote: > In SW pipeline path of Box/Gaussian Blur/Shadow effects we are not checking > for range when we read data from the source/destination buffers in native > code. > > We need to add appropriate range checks in native JNI code also apart from > range checks in Java side to make sure that wherever these JNI methods are > used we are not performing out of bounds access. This pull request has now been integrated. Changeset: 96e5d10a Author:Jayathirth D V Committer: Nir Lisker URL: https://git.openjdk.org/jfx/commit/96e5d10a40dc25b999ff229f1d6601d1058761b2 Stats: 85 lines in 6 files changed: 85 ins; 0 del; 0 mod 8319079: Missing range checks in decora Reviewed-by: kcr, arapte - PR: https://git.openjdk.org/jfx/pull/1272
Re: RFR: 8319079: Missing range checks in decora [v2]
On Tue, 31 Oct 2023 14:54:01 GMT, Kevin Rushforth wrote: >> Jayathirth D V has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Add common util function > > modules/javafx.graphics/src/main/native-decora/SSEUtils.cc line 187: > >> 185: } >> 186: >> 187: bool checkRange(JNIEnv *env, > > It would be helpful to add a comment indicating that this will return true if > the range check fails and false if it is OK. @kevinrushforth thanks for your inputs. I thought for sometime about how to name this function like notInRange() or outOfRange() but since it is checking so many parameters i didn't change function name. I have added comment about what the function is doing as pointed by you. Also @arapte mentioned a small nit offline about how we can keep src/dst arguments on same line instead of dividing them. I have updated that also. - PR Review Comment: https://git.openjdk.org/jfx/pull/1272#discussion_r1379662928
Re: RFR: 8319079: Missing range checks in decora [v3]
> In SW pipeline path of Box/Gaussian Blur/Shadow effects we are not checking > for range when we read data from the source/destination buffers in native > code. > > We need to add appropriate range checks in native JNI code also apart from > range checks in Java side to make sure that wherever these JNI methods are > used we are not performing out of bounds access. Jayathirth D V has updated the pull request incrementally with two additional commits since the last revision: - Update checkRange arguments indentation - Add checkRange function comment - Changes: - all: https://git.openjdk.org/jfx/pull/1272/files - new: https://git.openjdk.org/jfx/pull/1272/files/5cccac6b..69739db9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1272&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1272&range=01-02 Stats: 45 lines in 6 files changed: 5 ins; 20 del; 20 mod Patch: https://git.openjdk.org/jfx/pull/1272.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1272/head:pull/1272 PR: https://git.openjdk.org/jfx/pull/1272
Re: RFR: 8319079: Missing range checks in decora [v2]
> In SW pipeline path of Box/Gaussian Blur/Shadow effects we are not checking > for range when we read data from the source/destination buffers in native > code. > > We need to add appropriate range checks in native JNI code also apart from > range checks in Java side to make sure that wherever these JNI methods are > used we are not performing out of bounds access. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Add common util function - Changes: - all: https://git.openjdk.org/jfx/pull/1272/files - new: https://git.openjdk.org/jfx/pull/1272/files/9b58348d..5cccac6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1272&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1272&range=00-01 Stats: 104 lines in 6 files changed: 24 ins; 40 del; 40 mod Patch: https://git.openjdk.org/jfx/pull/1272.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1272/head:pull/1272 PR: https://git.openjdk.org/jfx/pull/1272
Re: RFR: 8319079: Missing range checks in decora [v2]
On Mon, 30 Oct 2023 15:16:45 GMT, Kevin Rushforth wrote:
>> modules/javafx.graphics/src/main/native-decora/SSELinearConvolveShadowPeer.cc
>> line 133:
>>
>>> 131: dstrows > srcrows) { // We should not move out of source
>>> vertical bounds
>>> 132: return;
>>> 133: }
>>
>> Instead of copy-pasting the same checks in all the missing places, isn't it
>> better to create a check method (say in `SSEUtils`) and call if from all the
>> places? Like in the style of `java.util.Objects::checkRange`.
>
> If the checks are identical, that could be a useful change.
Thanks for the inputs.
Apart from single check all others are identical, so i have added common
utility function.
-
PR Review Comment: https://git.openjdk.org/jfx/pull/1272#discussion_r1377084907
RFR: 8319079: Missing range checks in decora
In SW pipeline path of Box/Gaussian Blur/Shadow effects we are not checking for range when we read data from the source/destination buffers in native code. We need to add appropriate range checks in native JNI code also apart from range checks in Java side to make sure that wherever these JNI methods are used we are not performing out of bounds access. - Commit messages: - 8319079: Missing range checks in decora Changes: https://git.openjdk.org/jfx/pull/1272/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1272&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319079 Stats: 116 lines in 5 files changed: 116 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1272.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1272/head:pull/1272 PR: https://git.openjdk.org/jfx/pull/1272
Re: [jfx-tests] RFR: 8315896: Perspective lod tests fail because of minute difference in values [v3]
> Two perspective lod tests fail because of minute differences in expected > values. > > Failing tests: > test/scenegraph/fx3d/lod/PerspectiveLodCameraTest.java: > test/scenegraph/fx3d/lod/PerspectiveLodGroupTest.java: > > Exception: > test test.scenegraph.fx3d.lod.LodTests.sphereInitialLightOnTest(): failure > org.jemmy.TimeoutExpiredException: State 'Expected 50180.140882730484, but > was 50180.137157440186' has not been reached in 1000 milliseconds > at org.jemmy.timing.Waiter.ensureValue(Waiter.java:93) > at test.scenegraph.fx3d.lod.LodTestBase.checkLod(LodTestBase.java:117) > at > test.scenegraph.fx3d.lod.LodTests.sphereInitialLightOnTest(LodTests.java:98) > at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:577) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299) > at > org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.lang.Thread.run(Thread.java:833) > > These little difference in values are seen both initial drawing and updates. > These tests are not run from long time and change in product might change lod > values. > > With updated lod values i have verified that both the tests pass in OpenGL > and Metal pipeline with both retina display(scale = 2) and external > monitor(scale = 1). Jayathirth D V 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: - Merge remote-tracking branch 'upstream/master' into lod_tests - Add lod tolerance - 8315896: Perspective lod tests fail because of minute difference in values - Changes: - all: https://git.openjdk.org/jfx-tests/pull/6/files - new: https://git.openjdk.org/jfx-tests/pull/6/files/7dcb21aa..70895516 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx-tests&pr=6&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx-tests&pr=6&range=01-02 Stats: 437 lines in 186 files changed: 277 ins; 16 del; 144 mod Patch: https://git.openjdk.org/jfx-tests/pull/6.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/6/head:pull/6 PR: https://git.openjdk.org/jfx-tests/pull/6
Re: [jfx-tests] RFR: 8315896: Perspective lod tests fail because of minute difference in values [v2]
> Two perspective lod tests fail because of minute differences in expected > values. > > Failing tests: > test/scenegraph/fx3d/lod/PerspectiveLodCameraTest.java: > test/scenegraph/fx3d/lod/PerspectiveLodGroupTest.java: > > Exception: > test test.scenegraph.fx3d.lod.LodTests.sphereInitialLightOnTest(): failure > org.jemmy.TimeoutExpiredException: State 'Expected 50180.140882730484, but > was 50180.137157440186' has not been reached in 1000 milliseconds > at org.jemmy.timing.Waiter.ensureValue(Waiter.java:93) > at test.scenegraph.fx3d.lod.LodTestBase.checkLod(LodTestBase.java:117) > at > test.scenegraph.fx3d.lod.LodTests.sphereInitialLightOnTest(LodTests.java:98) > at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:577) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299) > at > org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.lang.Thread.run(Thread.java:833) > > These little difference in values are seen both initial drawing and updates. > These tests are not run from long time and change in product might change lod > values. > > With updated lod values i have verified that both the tests pass in OpenGL > and Metal pipeline with both retina display(scale = 2) and external > monitor(scale = 1). Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Add lod tolerance - Changes: - all: https://git.openjdk.org/jfx-tests/pull/6/files - new: https://git.openjdk.org/jfx-tests/pull/6/files/e6c3308b..7dcb21aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx-tests&pr=6&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx-tests&pr=6&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx-tests/pull/6.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/6/head:pull/6 PR: https://git.openjdk.org/jfx-tests/pull/6
Re: [jfx-tests] RFR: 8315896: Perspective lod tests fail because of minute difference in values
On Fri, 8 Sep 2023 13:13:56 GMT, Kevin Rushforth wrote: > Two questions: > > 1. Have you run this on Windows to ensure that the D3D pipeline also > passes with this change? > > 2. It might be better to compare using a tolerance rather than relying on > an exact value being computed in floating-point arithmetic. Thanks @kevinrushforth for your inputs. I have added tolerance which is definitely better than using fixed value for lod. I have tried running jfx-tests using cygwin as well as cmd in windows. For cygwin i followed same approach as we follow for macOS but with different path separator. Also https://ant.apache.org/manual/running.html talks about not using cygwin path for ant -Dproperty and i used absolute path. With all these still ant is not able to find javafx.home and jemmy-v3.jars. But with same path pattern it is able to find jtreg.home. For cmd, i added needed environment variables but there also i am not able to run the tests. I think its better to handle making jfx-tests run in Windows as part of separate bug. Current change without verification in D3D will help in atleast comparing functionality between OpenGL and Metal in macOS. - PR Comment: https://git.openjdk.org/jfx-tests/pull/6#issuecomment-1744315190
[jfx-tests] Integrated: 8316807: Exclude 3D subscene perspective camera picking tests
On Fri, 29 Sep 2023 11:03:56 GMT, Jayathirth D V wrote: > While debugging subscene picking tests it was identified that in subscene > mouse events are not captured when we click on area where nothing is drawn or > filled. > All the picking tests actually click on these null points and expect a mouse > event. This causes TimeoutExpiredException when subscene is used. > > Also we add borders to subscene and expect it to return same pickresults as > in scene. > Removed borders for subscene and also added mouse event handler on scene > itself. Adding mouse event handler on scene resolves TimeoutExpiredException > but still the subscene tests continue to fail. > > Currently we are trying to stabilize as many tests as possible to use these > automated tests for Metal pipeline implementation. To continue more > investigation regarding these failures i have created : > https://bugs.openjdk.org/browse/JDK-8317309 and to update subscene > specification for difference in how mouse event are handled i have created : > https://bugs.openjdk.org/browse/JDK-8317310 > > We should problem list these tests and continue debugging as part of separate > bug : https://bugs.openjdk.org/browse/JDK-8317309 This pull request has now been integrated. Changeset: 780824d1 Author:Jayathirth D V Committer: Ajit Ghaisas URL: https://git.openjdk.org/jfx-tests/commit/780824d15bd3629854528164727fcbe41202e784 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod 8316807: Exclude 3D subscene perspective camera picking tests Reviewed-by: aghaisas - PR: https://git.openjdk.org/jfx-tests/pull/13
[jfx-tests] RFR: 8316807: Exclude 3D subscene perspective camera picking tests
While debugging subscene picking tests it was identified that in subscene mouse events are not captured when we click on area where nothing is drawn or filled. All the picking tests actually click on these null points and expect a mouse event. This causes TimeoutExpiredException when subscene is used. Also we add borders to subscene and expect it to return same pickresults as in scene. Removed borders for subscene and also added mouse event handler on scene itself. Adding mouse event handler on scene resolves TimeoutExpiredException but still the subscene tests continue to fail. Currently we are trying to stabilize as many tests as possible to use these automated tests for Metal pipeline implementation. To continue more investigation regarding these failures i have created : https://bugs.openjdk.org/browse/JDK-8317309 and to update subscene specification for difference in how mouse event are handled i have created : https://bugs.openjdk.org/browse/JDK-8317310 We should problem list these tests and continue debugging as part of separate bug : https://bugs.openjdk.org/browse/JDK-8317309 - Commit messages: - 8316807: Exclude 3D subscene perspective camera picking tests Changes: https://git.openjdk.org/jfx-tests/pull/13/files Webrev: https://webrevs.openjdk.org/?repo=jfx-tests&pr=13&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316807 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx-tests/pull/13.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/13/head:pull/13 PR: https://git.openjdk.org/jfx-tests/pull/13
[jfx-tests] Integrated: 8316490: Problemlist ParallelCamera picking tests
On Fri, 22 Sep 2023 09:40:31 GMT, Jayathirth D V wrote: > When we run 3D picking tests under test/scenegraph/fx3d/picking/parallel/ > nothing is displayed on the window and subscene parallel camera tests under > test/scenegraph/fx3d/subscene/picking/parallel/ throw > UnsupportedOperationException. > > Subscene parallel camera tests are incomplete and even if we update the tests > nothing will be shown because of product issue > https://bugs.openjdk.org/browse/JDK-8165941. > > ParallelCamera forces near and far clip to be between -viewWidthOrHeight/2 > and viewWidthOrHeight/2. So in these test cases we generate a mesh and then > scale it 100x. After that we move camera to large -z position to make content > visible. This causes content to move into clipping area in case of > ParallelCamera. Until https://bugs.openjdk.org/browse/JDK-8165941 is fixed we > should problemlist these tests. This pull request has now been integrated. Changeset: 5fc5fb52 Author:Jayathirth D V Committer: Ajit Ghaisas URL: https://git.openjdk.org/jfx-tests/commit/5fc5fb5205d4cb1aeaa008d220be4aef0f6c36ae Stats: 9 lines in 2 files changed: 8 ins; 0 del; 1 mod 8316490: Problemlist ParallelCamera picking tests Reviewed-by: aghaisas - PR: https://git.openjdk.org/jfx-tests/pull/12
[jfx-tests] RFR: 8316490: Problemlist ParallelCamera picking tests
When we run 3D picking tests under test/scenegraph/fx3d/picking/parallel/ nothing is displayed on the window and subscene parallel camera tests under test/scenegraph/fx3d/subscene/picking/parallel/ throw UnsupportedOperationException. Subscene parallel camera tests are incomplete and even if we update the tests nothing will be shown because of product issue https://bugs.openjdk.org/browse/JDK-8165941. ParallelCamera forces near and far clip to be between -viewWidthOrHeight/2 and viewWidthOrHeight/2. So in these test cases we generate a mesh and then scale it 100x. After that we move camera to large -z position to make content visible. This causes content to move into clipping area in case of ParallelCamera. Until https://bugs.openjdk.org/browse/JDK-8165941 is fixed we should problemlist these tests. - Commit messages: - 8316490: Problemlist ParallelCamera picking tests Changes: https://git.openjdk.org/jfx-tests/pull/12/files Webrev: https://webrevs.openjdk.org/?repo=jfx-tests&pr=12&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316490 Stats: 9 lines in 2 files changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx-tests/pull/12.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/12/head:pull/12 PR: https://git.openjdk.org/jfx-tests/pull/12
[jfx21u] Integrated: 8315074: Possible null pointer access in native glass
On Wed, 13 Sep 2023 16:01:34 GMT, Jayathirth D V wrote: > This is jfx21u backport of https://bugs.openjdk.org/browse/JDK-8315074. > It adds appropriate null checks in glass code. This pull request has now been integrated. Changeset: c80b74a2 Author:Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx21u/commit/c80b74a24c35be1128d8bf7f3a004feea79e7b3b Stats: 105 lines in 8 files changed: 70 ins; 7 del; 28 mod 8315074: Possible null pointer access in native glass Backport-of: f7b21e5468f1aad18df17443590c0887b2cf0239 - PR: https://git.openjdk.org/jfx21u/pull/15
[jfx21u] RFR: 8315074: Possible null pointer access in native glass
This is jfx21u backport of https://bugs.openjdk.org/browse/JDK-8315074. It adds appropriate null checks in glass code. - Commit messages: - Backport f7b21e5468f1aad18df17443590c0887b2cf0239 Changes: https://git.openjdk.org/jfx21u/pull/15/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=15&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315074 Stats: 105 lines in 8 files changed: 70 ins; 7 del; 28 mod Patch: https://git.openjdk.org/jfx21u/pull/15.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/15/head:pull/15 PR: https://git.openjdk.org/jfx21u/pull/15
Integrated: 8315074: Possible null pointer access in native glass
On Mon, 28 Aug 2023 04:58:31 GMT, Jayathirth D V wrote: > At multiple places in native glass code we don't have appropriate NULL checks > which might result in null pointer access. > > Added appropriate checks and all test run is green. This pull request has now been integrated. Changeset: f7b21e54 Author: Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/f7b21e5468f1aad18df17443590c0887b2cf0239 Stats: 105 lines in 8 files changed: 70 ins; 7 del; 28 mod 8315074: Possible null pointer access in native glass Reviewed-by: jvos, kcr - PR: https://git.openjdk.org/jfx/pull/1223
Re: [jfx-tests] RFR: JDK-8315895: Some 3D camera tests fail because of NPE
On Fri, 8 Sep 2023 17:05:41 GMT, Alexandre Iline wrote: >> There was a field in a subclass hiding a field in a superclass. > > @jayathirthrao FYI Thanks @shurymury for fixing this. I have verified that this change fixes subtests which were failing because of `java.lang.NullPointerException: Cannot invoke "javafx.scene.Camera.setNearClip(double)" because "this.camera" is null ` LGTM. - PR Comment: https://git.openjdk.org/jfx-tests/pull/8#issuecomment-1713307191
[jfx-tests] Integrated: 8315842: 3D tests fail because of edge pixel differences
On Thu, 7 Sep 2023 10:17:28 GMT, Jayathirth D V wrote: > Out of 62 3D tests, 26 tests fail because of minute color differences in edge > pixels. > These tests are used to verify 3D rendering with different parameters like > translation, rotation. > > So adding little color tolerance will not change the test behavior and allows > us to use these tests to automatically verify any regression introduced in 3D > rendering. > > Added 5% color tolerance and with this change 23 of these tests pass. > > Some sub-tests under below 3 tests continue to fail because of other reasons: > [test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.jtr) > [test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.jtr) > [test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.jtr) > > Also i see that some of the camera tests just draw white images, this also > needs to be verified. > With this change 41 out of 62 3D tests will run properly. This pull request has now been integrated. Changeset: 0d35c195 Author:Jayathirth D V Committer: Ajit Ghaisas URL: https://git.openjdk.org/jfx-tests/commit/0d35c195e060d6c3e77424853417d2a5fd47620c Stats: 171 lines in 27 files changed: 171 ins; 0 del; 0 mod 8315842: 3D tests fail because of edge pixel differences Reviewed-by: aghaisas - PR: https://git.openjdk.org/jfx-tests/pull/5
Re: [jfx-tests] RFR: 8315842: 3D tests fail because of edge pixel differences
On Thu, 7 Sep 2023 10:17:28 GMT, Jayathirth D V wrote: > Out of 62 3D tests, 26 tests fail because of minute color differences in edge > pixels. > These tests are used to verify 3D rendering with different parameters like > translation, rotation. > > So adding little color tolerance will not change the test behavior and allows > us to use these tests to automatically verify any regression introduced in 3D > rendering. > > Added 5% color tolerance and with this change 23 of these tests pass. > > Some sub-tests under below 3 tests continue to fail because of other reasons: > [test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.jtr) > [test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.jtr) > [test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.jtr) > > Also i see that some of the camera tests just draw white images, this also > needs to be verified. > With this change 41 out of 62 3D tests will run properly. > Not sure if it's relevant, but when I wrote a 3D test with a color tolerance > value it turned out to be too low on Mac (but not on Windows), as Kevin > pointed out to me: [openjdk/jfx#43 > (comment)](https://github.com/openjdk/jfx/pull/43#discussion_r502049390). We > ended up using his suggested value (10/255 =~ 0.04) because it was good > enough, but it could probably be a bit lower. Thanks @nlisker for your inputs. Current change of 0.05 tolerance is tested on Mac only. - PR Comment: https://git.openjdk.org/jfx-tests/pull/5#issuecomment-1713182541
Re: [jfx-tests] RFR: 8315842: 3D tests fail because of edge pixel differences [v2]
> Out of 62 3D tests, 26 tests fail because of minute color differences in edge > pixels. > These tests are used to verify 3D rendering with different parameters like > translation, rotation. > > So adding little color tolerance will not change the test behavior and allows > us to use these tests to automatically verify any regression introduced in 3D > rendering. > > Added 5% color tolerance and with this change 23 of these tests pass. > > Some sub-tests under below 3 tests continue to fail because of other reasons: > [test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.jtr) > [test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.jtr) > [test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.jtr) > > Also i see that some of the camera tests just draw white images, this also > needs to be verified. > With this change 41 out of 62 3D tests will run properly. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Use common tolerance variable - Changes: - all: https://git.openjdk.org/jfx-tests/pull/5/files - new: https://git.openjdk.org/jfx-tests/pull/5/files/70f97e8c..b3d3aa25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx-tests&pr=5&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx-tests&pr=5&range=00-01 Stats: 53 lines in 27 files changed: 27 ins; 0 del; 26 mod Patch: https://git.openjdk.org/jfx-tests/pull/5.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/5/head:pull/5 PR: https://git.openjdk.org/jfx-tests/pull/5
Re: [jfx-tests] RFR: 8315842: 3D tests fail because of edge pixel differences
On Fri, 8 Sep 2023 12:15:35 GMT, Ajit Ghaisas wrote: > A static constant can be added to > `test.scenegraph.fx3d.utils.FX3DAbstractApp` public static final float > COLOR_TOLERANCE = 0.05f; > > This can easily be accessed in test classes without FX3DAbstractApp instance > as - `Root.ROOT.getEnvironment().setProperty(ImageComparator.class, new > GlassPixelImageComparator(new > PixelEqualityRasterComparator(FX3DAbstractApp.COLOR_TOLERANCE)));` > > This will allow us to tweak the tolerance value at a single place in future > and not in all the 26 files. > > This change is pretty safe as and just a sanity check would be needed. If a > test does not use FX3DAbstractApp, then you can keep the hard-coded constant. Thanks @aghaisas for your inputs. I have updated the code to use common variable. - PR Comment: https://git.openjdk.org/jfx-tests/pull/5#issuecomment-1713179402
[jfx-tests] Integrated: 8315839: 3D shape tests fail because of invalid file path
On Thu, 7 Sep 2023 07:58:08 GMT, Jayathirth D V wrote: > Currently only 18 out of 62 3D tests run properly in jfx-tests repo. > All the shape tests under "test/scenegraph/fx3d/shapes" and > "test/scenegraph/fx3d/subscene/shapes" fail because they are not able to find > image input they need. > > Image files currently are at wrong place and they are moved to proper path > where they are expected by these tests. This is first step for stabilizing 3D > tests. Even with this change these test continue to fail because of some edge > pixels are differing by minute value. Mostly we will add color tolerance to > make these tests pass which will be taken up in follow-up bug. > > After this change we don't see "java.lang.IllegalArgumentException: Invalid > URL: Invalid URL or resource not found" in these tests. This pull request has now been integrated. Changeset: 30c25292 Author:Jayathirth D V Committer: Ajit Ghaisas URL: https://git.openjdk.org/jfx-tests/commit/30c252929c3f8101c6e95972a0d14bdfdc8686d6 Stats: 0 lines in 4 files changed: 0 ins; 0 del; 0 mod 8315839: 3D shape tests fail because of invalid file path Reviewed-by: aghaisas - PR: https://git.openjdk.org/jfx-tests/pull/3
Re: [jfx-tests] RFR: 8315842: 3D tests fail because of edge pixel differences
On Fri, 8 Sep 2023 10:27:45 GMT, Ajit Ghaisas wrote: > The changes are fine and they work. One suggestion is to define a common > constant for 5% of tolerance value rather than using 0.05 in each of the > changed file. This will allow us to adjust the tolerance percentage more > easily in future. One possible place to define this constant is - > `test.scenegraph.fx3d.utils.FX3DAbstractApp` as this class is imported in all > the test cases. I added tolerance variable in `test.scenegraph.fx3d.utils.FX3DAbstractApp` but i can access the member variable only after we get its instance at the end of setUp() functions of each test. We do other things before call getInstance() and the suggestion to set tolerance was at the start of these setUp() functions. Right now i am not sure whether we can add tolerance at the end of setUp() functions and how it might change test behaviour. Its better to add the common tolerance variable in a separate fix with additional verification. - PR Comment: https://git.openjdk.org/jfx-tests/pull/5#issuecomment-1711522136
[jfx-tests] RFR: 8315896: Perspective lod tests fail because of minute difference in values
Two perspective lod tests fail because of minute differences in expected values. Failing tests: test/scenegraph/fx3d/lod/PerspectiveLodCameraTest.java: test/scenegraph/fx3d/lod/PerspectiveLodGroupTest.java: Exception: test test.scenegraph.fx3d.lod.LodTests.sphereInitialLightOnTest(): failure org.jemmy.TimeoutExpiredException: State 'Expected 50180.140882730484, but was 50180.137157440186' has not been reached in 1000 milliseconds at org.jemmy.timing.Waiter.ensureValue(Waiter.java:93) at test.scenegraph.fx3d.lod.LodTestBase.checkLod(LodTestBase.java:117) at test.scenegraph.fx3d.lod.LodTests.sphereInitialLightOnTest(LodTests.java:98) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:577) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299) at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.lang.Thread.run(Thread.java:833) These little difference in values are seen both initial drawing and updates. These tests are not run from long time and change in product might change lod values. With updated lod values i have verified that both the tests pass in OpenGL and Metal pipeline with both retina display(scale = 2) and external monitor(scale = 1). - Commit messages: - 8315896: Perspective lod tests fail because of minute difference in values Changes: https://git.openjdk.org/jfx-tests/pull/6/files Webrev: https://webrevs.openjdk.org/?repo=jfx-tests&pr=6&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315896 Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jfx-tests/pull/6.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/6/head:pull/6 PR: https://git.openjdk.org/jfx-tests/pull/6
Re: [jfx-tests] RFR: 8315845: Exclude Scenegraph and Charts test classes that serve as a base class
On Thu, 7 Sep 2023 09:26:59 GMT, Ajit Ghaisas wrote: > A few SceneGraphTests and ControlsTests/chart test classes are abstract > classes and serve as base classes for other tests. > They are excluded from test execution and hence result in avoiding false > failure reports. LGTM. I think in 3D tests also we have similar problem. When i run sub-folders it runs some files which i think should not be run in standlone mode and they throw `java.lang.InstantiationException` - Marked as reviewed by jdv (Author). PR Review: https://git.openjdk.org/jfx-tests/pull/4#pullrequestreview-1616835565
[jfx-tests] RFR: 8315842: 3D tests fail because of edge pixel differences
Out of 62 3D tests, 26 tests fail because of minute color differences in edge pixels. These tests are used to verify 3D rendering with different parameters like translation, rotation. So adding little color tolerance will not change the test behavior and allows us to use these tests to automatically verify any regression introduced in 3D rendering. Added 5% color tolerance and with this change 23 of these tests pass. Some sub-tests under below 3 tests continue to fail because of other reasons: [test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.jtr) [test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.jtr) [test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.jtr) Also i see that some of the camera tests just draw white images, this also needs to be verified. With this change 41 out of 62 3D tests will run properly. - Commit messages: - 8315842: 3D tests fail because of edge pixel differences Changes: https://git.openjdk.org/jfx-tests/pull/5/files Webrev: https://webrevs.openjdk.org/?repo=jfx-tests&pr=5&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315842 Stats: 144 lines in 26 files changed: 144 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx-tests/pull/5.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/5/head:pull/5 PR: https://git.openjdk.org/jfx-tests/pull/5
[jfx-tests] RFR: 8315839: 3D shape tests fail because of invalid file path
Currently only 18 out of 62 3D tests run properly in jfx-tests repo. All the shape tests under "test/scenegraph/fx3d/shapes" and "test/scenegraph/fx3d/subscene/shapes" fail because they are not able to find image input they need. Image files currently are at wrong place and they are moved to proper path where they are expected by these tests. This is first step for stabilizing 3D tests. Even with this change these test continue to fail because of some edge pixels are differing by minute value. Mostly we will add color tolerance to make these tests pass which will be taken up in follow-up bug. After this change we don't see "java.lang.IllegalArgumentException: Invalid URL: Invalid URL or resource not found" in these tests. - Commit messages: - 8315839: 3D shape tests fail because of invalid file path Changes: https://git.openjdk.org/jfx-tests/pull/3/files Webrev: https://webrevs.openjdk.org/?repo=jfx-tests&pr=3&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315839 Stats: 0 lines in 4 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx-tests/pull/3.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/3/head:pull/3 PR: https://git.openjdk.org/jfx-tests/pull/3
Re: RFR: 8315074: Possible null pointer access in native glass [v2]
On Tue, 29 Aug 2023 07:03:32 GMT, Marius Hanl wrote:
>> Jayathirth D V has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix typo
>
> modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp line
> 270:
>
>> 268: // we release this context in call_runnable
>> 269: } else {
>> 270: fprintf(stderr, "malloc failed in
>> GtkApplication__1submitForLaterInvocatio\n");
>
> an `n` is missing in `submitForLaterInvocatio` <-
Thanks updated.
-
PR Review Comment: https://git.openjdk.org/jfx/pull/1223#discussion_r1310480031
Re: RFR: 8315074: Possible null pointer access in native glass [v2]
> At multiple places in native glass code we don't have appropriate NULL checks > which might result in null pointer access. > > Added appropriate checks and all test run is green. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Fix typo - Changes: - all: https://git.openjdk.org/jfx/pull/1223/files - new: https://git.openjdk.org/jfx/pull/1223/files/e6175de4..68e3b196 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1223&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1223&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1223.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1223/head:pull/1223 PR: https://git.openjdk.org/jfx/pull/1223
RFR: 8315074: Possible null pointer access in native glass
At multiple places in native glass code we don't have appropriate NULL checks which might result in null pointer access. Added appropriate checks and all test run is green. - Commit messages: - 8315074: Possible null pointer access in native glass Changes: https://git.openjdk.org/jfx/pull/1223/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1223&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315074 Stats: 105 lines in 8 files changed: 70 ins; 7 del; 28 mod Patch: https://git.openjdk.org/jfx/pull/1223.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1223/head:pull/1223 PR: https://git.openjdk.org/jfx/pull/1223
Re: RFR: 8314149: Clipboard does inexact string comparison on mime type [v2]
On Mon, 14 Aug 2023 09:18:00 GMT, Ambarish Rapte wrote: >> The mime name should be exactly same as the mime type supported by platform. >> Hence the comparison should not match partially similar names. >> Added an invalid unit test. >> >> @kevinrushforth @jayathirthrao please review > > Ambarish Rapte has updated the pull request incrementally with one additional > commit since the last revision: > > revert test Marked as reviewed by jdv (Author). - PR Review: https://git.openjdk.org/jfx/pull/1207#pullrequestreview-1579733570
Re: RFR: 8314149: Clipboard does inexact string comparison on mime type
On Fri, 11 Aug 2023 07:20:15 GMT, Ambarish Rapte wrote: > The mime name should be exactly same as the mime type supported by platform. > Hence the comparison should not match partially similar names. > Added an invalid unit test. > > @kevinrushforth @jayathirthrao please review Marked as reviewed by jdv (Author). - PR Review: https://git.openjdk.org/jfx/pull/1207#pullrequestreview-1573232416
Re: RFR: 8314141: Missing default for switch in CreateBitmap
On Fri, 11 Aug 2023 06:14:58 GMT, Ambarish Rapte wrote: > This is a simple change to add a missing default statement. > @kevinrushforth @jayathirthrao please review. Marked as reviewed by jdv (Author). - PR Review: https://git.openjdk.org/jfx/pull/1206#pullrequestreview-1573221415
[jfx21u] Integrated: 8313856: Replace VLA with malloc in pango
On Wed, 9 Aug 2023 05:13:36 GMT, Jayathirth D V wrote: > This is backport of https://bugs.openjdk.org/browse/JDK-8313856 to jfx21u. > > We should not use stack memory for large VLA allocations in pango.c This pull request has now been integrated. Changeset: 4ff0b7d8 Author:Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx21u/commit/4ff0b7d851bc78e2a3f806a6225d73e63b41a037 Stats: 26 lines in 1 file changed: 22 ins; 0 del; 4 mod 8313856: Replace VLA with malloc in pango Backport-of: 1752b62320f9e42f6d0d2c1f8278cf2ab205a8f4 - PR: https://git.openjdk.org/jfx21u/pull/8
Re: [jfx21u] RFR: 8313856: Replace VLA with malloc in pango
On Wed, 9 Aug 2023 05:13:36 GMT, Jayathirth D V wrote: > This is backport of https://bugs.openjdk.org/browse/JDK-8313856 to jfx21u. > > We should not use stack memory for large VLA allocations in pango.c @kevinrushforth and @arapte please review. - PR Comment: https://git.openjdk.org/jfx21u/pull/8#issuecomment-1670699574
[jfx21u] RFR: 8313856: Replace VLA with malloc in pango
This is backport of https://bugs.openjdk.org/browse/JDK-8313856 to jfx21u. We should not use stack memory for large VLA allocations in pango.c - Commit messages: - Backport 1752b62320f9e42f6d0d2c1f8278cf2ab205a8f4 Changes: https://git.openjdk.org/jfx21u/pull/8/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=8&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313856 Stats: 26 lines in 1 file changed: 22 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx21u/pull/8.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/8/head:pull/8 PR: https://git.openjdk.org/jfx21u/pull/8
Integrated: 8313856: Replace VLA with malloc in pango
On Mon, 7 Aug 2023 04:55:23 GMT, Jayathirth D V wrote: > We should not use stack for array memory allocations in JNI. > Updated pango.c to use malloc for arrays and release them at appropriate > places. This pull request has now been integrated. Changeset: 1752b623 Author:Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/1752b62320f9e42f6d0d2c1f8278cf2ab205a8f4 Stats: 26 lines in 1 file changed: 22 ins; 0 del; 4 mod 8313856: Replace VLA with malloc in pango Reviewed-by: arapte, kcr - PR: https://git.openjdk.org/jfx/pull/1202
RFR: 8313856: Replace VLA with malloc in pango
We should not use stack for array memory allocations in JNI. Updated pango.c to use malloc for arrays and release them at appropriate places. - Commit messages: - 8313856: Replace VLA with malloc in pango Changes: https://git.openjdk.org/jfx/pull/1202/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1202&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313856 Stats: 26 lines in 1 file changed: 22 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1202.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1202/head:pull/1202 PR: https://git.openjdk.org/jfx/pull/1202
Integrated: 8309508: Possible memory leak in JPEG image loader
On Fri, 9 Jun 2023 05:18:16 GMT, Jayathirth D V wrote: > On code inspection it is revealed that in jpegloader.c->decompressIndirect() > we are allocating memory for "scanline_ptr", but if we error_exit() from > jpeg_read_scanlines() we are not releasing this memory. > > Added release of "scanline_ptr" with NULL check at appropriate places. > As part of this fix also added RELEASE_ARRAYS() call for stream/pixel buffer > in all cases where we move back to Java code. > > Its difficult to create definite pass/fail regression test for memory leak, > added noreg-hard label in JBS. This pull request has now been integrated. Changeset: bd24fc72 Author:Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/bd24fc7286725358f109863e6cc8a6c3abb354e1 Stats: 14 lines in 1 file changed: 9 ins; 0 del; 5 mod 8309508: Possible memory leak in JPEG image loader Reviewed-by: kcr, arapte - PR: https://git.openjdk.org/jfx/pull/1151
RFR: 8309508: Possible memory leak in JPEG image loader
On code inspection it is revealed that in jpegloader.c->decompressIndirect() we are allocating memory for "scanline_ptr", but if we error_exit() from jpeg_read_scanlines() we are not releasing this memory. Added release of "scanline_ptr" with NULL check at appropriate places. As part of this fix also added RELEASE_ARRAYS() call for stream/pixel buffer in all cases where we move back to Java code. Its difficult to create definite pass/fail regression test for memory leak, added noreg-hard label in JBS. - Commit messages: - 8309508: Possible memory leak in JPEG image loader Changes: https://git.openjdk.org/jfx/pull/1151/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1151&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309508 Stats: 14 lines in 1 file changed: 9 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1151.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1151/head:pull/1151 PR: https://git.openjdk.org/jfx/pull/1151
