Integrated: 8323879: constructor Path(Path) which takes another Path object fail to draw on canvas html

2024-01-21 Thread Jay Bhaskar
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]

2024-01-21 Thread Jose Pereda
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

2024-01-21 Thread Nir Lisker
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