Integrated: 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html
On Thu, 18 Jan 2024 03:51:28 GMT, Jay Bhaskar wrote: > Issue: constructor Path(Path) which takes another Path object fails to draw > on canvas html. > Solution: copy the old path while creating a new Path object from the > existing Path that is already created with the same canvas rendering context. This pull request has now been integrated. Changeset: 3cf9390f Author:Jay Bhaskar URL: https://git.openjdk.org/jfx/commit/3cf9390f5fb2ad564eeec3a95744503f1b26dd0d Stats: 62 lines in 2 files changed: 61 ins; 0 del; 1 mod 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html Reviewed-by: kcr, hmeda - PR: https://git.openjdk.org/jfx/pull/1339
Re: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3]
On Mon, 18 Dec 2023 22:00:28 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add compile-time checks to GdkSeat > > The addition of the compile-time flags looks OK. > > I did a build with GTK 3.22 (so it compiles the new code, does the dlsym, and > does the runtime check) and verified that there are no regressions when > running on an older system (Ubuntu 16.04). > > I then did a full test run on our headful test systems, and there is one new > test failure -- it seems to be intermittent, although fails pretty > consistently on our Ubuntu 22.04 and Ubuntu 20.04 test systems. I can > reproduce it locally on a VM running Ubuntu 22.04, where it fails about 1/2 > the time with this patch applied (it fails more often on our physical test > systems). > > > DatePickerTest > testDatePickerSceneChange FAILED > java.lang.AssertionError: Timeout: Failed to receive onAction call. > at org.junit.Assert.fail(Assert.java:89) > at org.junit.Assert.assertTrue(Assert.java:42) > at test.util.Util.waitForLatch(Util.java:400) > at > test.robot.javafx.scene.DatePickerTest.clickDatePickerCalendarPopup(DatePickerTest.java:90) > at > test.robot.javafx.scene.DatePickerTest.testDatePickerSceneChange(DatePickerTest.java:123) > > > Not sure what to make of this. I am not aware of any problems with this test, > but it's possible that your fix has exposed a latent issue either in the test > or somewhere else. @kevinrushforth is there anything else to be done before we can move this PR forward? - PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1902776414
Re: RFR: 8324219: Remove incorrect documentation from Animation methods
On Fri, 19 Jan 2024 16:07:31 GMT, Michael Strauß wrote: > The `Animation` class states in the documentation of various methods that the > method call would be asynchronous, using language similar to: > > > {@code stop()} is an asynchronous call, the {@code Animation} may not stop > immediately. > > > This is factually wrong, there are no asynchronous calls. In fact, the > methods in question can only be called synchronously on the JavaFX > Application thread, and the state of the animation is changed immediately. > For example, when `stop()` is called, the animation transitions to the > stopped state instantly, without waiting for the next animation pulse. Looks fine, but I'd like to see what Jurgen's case is on the mailing list. - Marked as reviewed by nlisker (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1342#pullrequestreview-1835435903