Re: RFR: 8285893: Hiding dialog and showing new one causes dialog to be frozen

[Martin Fox]

On Thu, 23 May 2024 14:21:27 GMT, Marius Hanl  wrote:

> That is exactly what I also figured out. If a second new nested event loop is 
> started directly after the first one was requested to leave, the native code 
> will never 'return'. That's why this code exists: 
> https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/EventLoop.java#L118
>  which I slightly modified to not run `invokeLater` in my PR.

I think the invokeLater call is required. On Mac and Windows calls into Glass 
can only affect the innermost loop. For each loop you want to exit you have to 
call `Application.leaveNestedEventLoop` and then allow the execution stack to 
unwind to Glass so it can remove the loop. Only then can you initiate the 
process of leaving the next loop. So if there’s multiple loops in a LEAVING 
state each one needs to be handled in a separate runnable so the execution 
stack can unwind between runnables.

When leaving the innermost loop the steps of interest are:

1. call Application.leaveNestedEventLoop
2. disable the InvokeLaterDispatcher
3. unwind the execution stack to glass
4. enable the InvokeLaterDispatcher

My tweak to the code ensures that the InvokeLaterDispatcher is re-enabled if we 
start at step 1 but enter a new event loop before we can reach step 3. On Mac 
and Windows we’ll always restart the leaving process at step 1 for all loops. 
That’s not happening on Linux, the old loop is leaving without starting at step 
1. I’m pretty sure this is opening a window where the InvokeLaterDispatcher can 
dispatch a runnable to the old loop while it’s leaving. That’s not supposed to 
happen but I’m not sure what the consequences might be on Linux (I know it 
would be very bad on Mac).

-

PR Comment: https://git.openjdk.org/jfx/pull/1449#issuecomment-2137836685

Re: [External] : Re: JavaFX TableView text in the cells of the columns seems to jump

[Andy Goryachev]

Unfortunately, this idea won't work in JavaFX, because it needs the change in 
the Skin/Behavior.

-andy

From: Mads 
Date: Tuesday, May 28, 2024 at 01:59
To: Andy Goryachev 
Cc: openjfx-dev@openjdk.org 
Subject: [External] : Re: JavaFX TableView text in the cells of the columns 
seems to jump
Hi Andy

Maybe a fix (quick?) could be a option to always show the scrollbar? I have 
used that option before in HTML/CSS: 
https://www.w3schools.com/howto/howto_css_force_scrollbars.asp

Kind Regards
Mads

Den tirs. 26. mar. 2024 kl. 16.31 skrev Andy Goryachev 
mailto:andy.goryac...@oracle.com>>:
Hi there.

Thank you for bringing this up in the mailing list (we **do not** monitor 
stackoverflow).

Do I understand it correctly from this stackoverflow posting that the problem 
is a momentary adjustment of the columns when the vertical scroll bar appears?  
And that it works correctly otherwise?

If that's the case, yes - this is the expected behavior, at least given the 
current design of the TableView skin.  If one adds a change listener to, let's 
say, the last column, one will see three updates:


  1.  in TableColumnHeader.doColumnAutoSize() as a response to setting the scene
  2.  TableColumnHeader.resizeColumnToFitContent(), called by 
TableViewSkinBase.updateContentWidth() as a response to Scene.doLayoutPass()
  3.  TableView.setContentWidth() as a response to 
VirtualFlow.computeBarVisibility() when it decides the vertical scroll bar 
needs to be shown.

What I can't tell is whether steps 2 and 2 can be combined - in other words, 
whether it is possible to know that the vertical scroll bar needs to be shown 
before the layout pass is done.  I am sure it can be in the case of the fixed 
row height, but if the row heights depend on the content width the things might 
get complicated.

If it can, we can try to investigate, though it will be a low priority 
enhancement (the table does work correctly save for a momentary flicker).  I am 
going to create a JBS ticket https://bugs.openjdk.org/browse/JDK-8329104 to 
investigate.

Cheers,
-andy






From: openjfx-dev 
mailto:openjfx-dev-r...@openjdk.org>> on behalf 
of Mads mailto:mailtiltss...@gmail.com>>
Date: Tuesday, March 26, 2024 at 05:58
To: openjfx-dev@openjdk.org 
mailto:openjfx-dev@openjdk.org>>
Subject: JavaFX TableView text in the cells of the columns seems to jump
Please see this Stack Overflow post where I have tried my best to document what 
is going on:

https://stackoverflow.com/questions/77369768/javafx-tableview-text-in-the-cells-of-the-columns-seems-to-jump

Seems to be an issue with CONSTRAINED_RESIZE_POLICY_ALL_COLUMNS when drawing 
the table for the first time and when vertical scrollbar is added?

Is this how it is intended to be?

Regards

Re: RFR: 8322964: Optimize performance of CSS selector matching [v13]

[Marius Hanl]

On Tue, 28 May 2024 21:44:36 GMT, John Hendrikx  wrote:

>> Improves performance of selector matching in the CSS subsystem. This is done 
>> by using custom set implementation which are highly optimized for the most 
>> common cases where the number of selectors is small (most commonly 1 or 2). 
>> It also should be more memory efficient for medium sized and large 
>> applications which have many style names defined in various CSS files.
>> 
>> Due to the optimization, the concept of `StyleClass`, which was only 
>> introduced to assign a fixed bit index for each unique style class name 
>> encountered, is no longer needed. This is because style classes are no 
>> longer stored in a `BitSet` which required a fixed index per encountered 
>> style class.
>> 
>> The performance improvements are the result of several factors:
>> - Less memory use when only very few style class names are used in selectors 
>> and styles from a large pool of potential styles (a `BitSet` for potentially 
>> 1000 different style names needed 1000 bits (worst case)  as it was not 
>> sparse).
>> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+)
>> - Specialized sets are append only (reduces code paths) and can be made read 
>> only without requiring a wrapper
>> - Iterator creation is avoided when doing `containsAll` check thanks to the 
>> inverse function `isSuperSetOf`
>> - Avoids making a copy of the list of style class names to compare (to 
>> convert them to `StyleClass` and put them into a `Set`) -- this copy could 
>> not be cached and was always discarded immediately after...
>> 
>> The overall performance was tested using the JFXCentral application which 
>> displays about 800 nodes on its start page with about 1000 styles in various 
>> style sheets (and which allows to refresh this page easily).  
>> 
>> On JavaFX 20, the fastest refresh speed was 121 ms on my machine.  With the 
>> improvements in this PR, the fastest refresh had become 89 ms.  The speed 
>> improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up 
>> the bulk of the time to refresh the JFXCentral main page (about 100 ms 
>> before vs 70 ms after the change).
>
> John Hendrikx has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Add copyright header

Marked as reviewed by mhanl (Committer).

-

PR Review: https://git.openjdk.org/jfx/pull/1316#pullrequestreview-2085844246

Re: RFR: 8332748: Grammatical errors in animation API docs [v2]

[Andy Goryachev]

On Wed, 29 May 2024 15:52:36 GMT, Lukasz Kostyra  wrote:

>> Checked code and fixed the gramatical error in Transition files: 
>> s/interval/intervals
>> 
>> Fill and Stroke Transition had correct grammatical form already, so those 
>> were untouched. I couldn't find any other instances of this error in our 
>> javadoc documentation.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Add missing fix for Scale Transition

Marked as reviewed by angorya (Reviewer).

-

PR Review: https://git.openjdk.org/jfx/pull/1466#pullrequestreview-2085812054

Re: RFR: 8332748: Grammatical errors in animation API docs [v2]

[Nir Lisker]

On Wed, 29 May 2024 15:52:36 GMT, Lukasz Kostyra  wrote:

>> Checked code and fixed the gramatical error in Transition files: 
>> s/interval/intervals
>> 
>> Fill and Stroke Transition had correct grammatical form already, so those 
>> were untouched. I couldn't find any other instances of this error in our 
>> javadoc documentation.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Add missing fix for Scale Transition

I think that 1 Reviewer is enough, but give it some time for others to have a 
chance to review.

-

Marked as reviewed by nlisker (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1466#pullrequestreview-2085810041

Re: RFR: 8332748: Grammatical errors in animation API docs

[Lukasz Kostyra]

On Wed, 29 May 2024 14:23:16 GMT, Nir Lisker  wrote:

> `ScaleTransition` is missing a fix.

Newline in the comment between "regular" and "interval" got me... Should be all 
good now.

-

PR Comment: https://git.openjdk.org/jfx/pull/1466#issuecomment-2137740568

Re: RFR: 8332748: Grammatical errors in animation API docs [v2]

[Lukasz Kostyra]

> Checked code and fixed the gramatical error in Transition files: 
> s/interval/intervals
> 
> Fill and Stroke Transition had correct grammatical form already, so those 
> were untouched. I couldn't find any other instances of this error in our 
> javadoc documentation.

Lukasz Kostyra has updated the pull request incrementally with one additional 
commit since the last revision:

  Add missing fix for Scale Transition

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1466/files
  - new: https://git.openjdk.org/jfx/pull/1466/files/db71ff37..295fed8c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx=1466=01
 - incr: https://webrevs.openjdk.org/?repo=jfx=1466=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1466.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1466/head:pull/1466

PR: https://git.openjdk.org/jfx/pull/1466

Re: JavaFX applications fail to build with Maven 3.9.7

[Johan Vos]

Yes, that is why I filed https://bugs.openjdk.org/browse/JDK-8333147
(which hints at a fix:
Instead of `classifier "$t.name"` we should now use `archiveClassifier.set(
t.name)`
)

- Johan

On Wed, May 29, 2024 at 4:58 PM John Neffenger  wrote:

> On 5/29/24 12:19 AM, Joeri Sykora wrote:
> > maven artifacts are generated when providing the following gradle
> > property: -PMAVEN_PUBLISH=true
>
> I can't get that to work. Is there some other option I need to pass?
>
> $ bash gradlew -PMAVEN_PUBLISH=true publishToMavenLocal
>
> FAILURE: Build failed with an exception.
>
> * Where:
> Build file '/home/ubuntu/src/jfx/build.gradle' line: 1734
>
> * What went wrong:
> A problem occurred configuring root project 'jfx'.
>  > Failed to notify project evaluation listener.
> > Could not find method classifier() for arguments [linux] on task
> ':base:modularPublicationJarLinux' of type
> org.gradle.api.tasks.bundling.Jar.
> > Could not find method classifier() for arguments [linux] on task
> ':graphics:modularPublicationJarLinux' of type
> org.gradle.api.tasks.bundling.Jar.
> > Could not find method classifier() for arguments [linux] on task
> ':controls:modularPublicationJarLinux' of type
> org.gradle.api.tasks.bundling.Jar.
> > Could not find method classifier() for arguments [linux] on task
> ':swing:modularPublicationJarLinux' of type
> org.gradle.api.tasks.bundling.Jar.
> > Could not find method classifier() for arguments [linux] on task
> ':fxml:modularPublicationJarLinux' of type
> org.gradle.api.tasks.bundling.Jar.
> > Could not find method classifier() for arguments [linux] on task
> ':media:modularPublicationJarLinux' of type
> org.gradle.api.tasks.bundling.Jar.
> > Could not find method classifier() for arguments [linux] on task
> ':web:modularPublicationJarLinux' of type
> org.gradle.api.tasks.bundling.Jar.
>
> John
>
>

Re: JavaFX applications fail to build with Maven 3.9.7

[John Neffenger]

On 5/29/24 12:19 AM, Joeri Sykora wrote:
maven artifacts are generated when providing the following gradle 
property: -PMAVEN_PUBLISH=true


I can't get that to work. Is there some other option I need to pass?

$ bash gradlew -PMAVEN_PUBLISH=true publishToMavenLocal

FAILURE: Build failed with an exception.

* Where:
Build file '/home/ubuntu/src/jfx/build.gradle' line: 1734

* What went wrong:
A problem occurred configuring root project 'jfx'.
> Failed to notify project evaluation listener.
   > Could not find method classifier() for arguments [linux] on task 
':base:modularPublicationJarLinux' of type 
org.gradle.api.tasks.bundling.Jar.
   > Could not find method classifier() for arguments [linux] on task 
':graphics:modularPublicationJarLinux' of type 
org.gradle.api.tasks.bundling.Jar.
   > Could not find method classifier() for arguments [linux] on task 
':controls:modularPublicationJarLinux' of type 
org.gradle.api.tasks.bundling.Jar.
   > Could not find method classifier() for arguments [linux] on task 
':swing:modularPublicationJarLinux' of type 
org.gradle.api.tasks.bundling.Jar.
   > Could not find method classifier() for arguments [linux] on task 
':fxml:modularPublicationJarLinux' of type 
org.gradle.api.tasks.bundling.Jar.
   > Could not find method classifier() for arguments [linux] on task 
':media:modularPublicationJarLinux' of type 
org.gradle.api.tasks.bundling.Jar.
   > Could not find method classifier() for arguments [linux] on task 
':web:modularPublicationJarLinux' of type org.gradle.api.tasks.bundling.Jar.


John

Re: JavaFX applications fail to build with Maven 3.9.7

[John Neffenger]

On 5/29/24 6:54 AM, Joeri Sykora wrote:

FYI, version 23-ea+20 should contain the fixed parent pom.


Works great! Thank you for the quick fix, Joeri.

John

Re: RFR: 8332748: Grammatical errors in animation API docs

[Nir Lisker]

On Wed, 29 May 2024 06:53:40 GMT, Lukasz Kostyra  wrote:

> Checked code and fixed the gramatical error in Transition files: 
> s/interval/intervals
> 
> Fill and Stroke Transition had correct grammatical form already, so those 
> were untouched. I couldn't find any other instances of this error in our 
> javadoc documentation.

`ScaleTransition` is missing a fix.

-

PR Comment: https://git.openjdk.org/jfx/pull/1466#issuecomment-2137545249

Re: JavaFX applications fail to build with Maven 3.9.7

[Joeri Sykora]

FYI, version 23-ea+20 should contain the fixed parent pom.

Op wo 29 mei 2024 om 09:31 schreef Michael Hall :

>
>
> On May 29, 2024, at 2:19 AM, Joeri Sykora  wrote:
>
> Hi John,
>
> maven artifacts are generated when providing the following gradle
> property: -PMAVEN_PUBLISH=true
>
> For the actual maven publication to maven central, Gluon uses a different
> parent pom file, which indeed has those duplicate profile id's.
> We'll provide a fix that will be available from 23-ea+19.
>
> As a workaround you can:
>
>- fallback to maven 3.9.6 or earlier
>- manually specify the javafx.platform property, i.e.: mvn
>-Djavafx.platform=linux compile
>
> Kind regards,
> Joeri
>
>
> Simply editing the file and deleting the duplicates also seemed to work
> for me. At least it ran the validate command successfully.
>
>

Re: RFR: 8289115: Touch events is not dispatched after upgrade to JAVAFX17+

[Michael Strauß]

On Tue, 28 May 2024 08:09:41 GMT, Florian Kirmaier  
wrote:

> I can confirm that this change fixes a Problem for more users. Actually, i 
> have a built with exactly the same change. So if this doesn't break anything, 
> it would be great to see this integrated.

Feel free to approve if you think the patch is good to go.

-

PR Comment: https://git.openjdk.org/jfx/pull/1459#issuecomment-2137251075

Integrated: 8087444: CornerRadii with different horizontal and vertical values treated as uniform

[Michael Strauß]

On Tue, 28 May 2024 16:15:25 GMT, Michael Strauß  wrote:

> This PR fixes the incorrect computation of the `CornerRadii.uniform` flag for 
> the 16-argument constructor.
> 
> I've also added tests for all other constructors.

This pull request has now been integrated.

Changeset: 2e1427e8
Author:Michael Strauß 
URL:   
https://git.openjdk.org/jfx/commit/2e1427e8c873c10c0929ffdf385bec305f13f41d
Stats: 82 lines in 2 files changed: 69 ins; 1 del; 12 mod

8087444: CornerRadii with different horizontal and vertical values treated as 
uniform

Reviewed-by: angorya, jhendrikx

-

PR: https://git.openjdk.org/jfx/pull/1465

Re: JavaFX applications fail to build with Maven 3.9.7

[Michael Hall]

> On May 29, 2024, at 2:19 AM, Joeri Sykora  wrote:
> 
> Hi John,
> 
> maven artifacts are generated when providing the following gradle property: 
> -PMAVEN_PUBLISH=true
> 
> For the actual maven publication to maven central, Gluon uses a different 
> parent pom file, which indeed has those duplicate profile id's.
> We'll provide a fix that will be available from 23-ea+19.
> 
> As a workaround you can:
> fallback to maven 3.9.6 or earlier
> manually specify the javafx.platform property, i.e.: mvn 
> -Djavafx.platform=linux compile
> Kind regards,
> Joeri
> 

Simply editing the file and deleting the duplicates also seemed to work for me. 
At least it ran the validate command successfully.

Re: JavaFX applications fail to build with Maven 3.9.7

[Joeri Sykora]

Hi John,

maven artifacts are generated when providing the following gradle property:
-PMAVEN_PUBLISH=true

For the actual maven publication to maven central, Gluon uses a different
parent pom file, which indeed has those duplicate profile id's.
We'll provide a fix that will be available from 23-ea+19.

As a workaround you can:

   - fallback to maven 3.9.6 or earlier
   - manually specify the javafx.platform property, i.e.: mvn
   -Djavafx.platform=linux compile

Kind regards,
Joeri

Op wo 29 mei 2024 om 04:30 schreef John Neffenger :

> It looks as if this issue was reported in 2021, 2022, and 2023. The
> difference now is that, as of Maven 3.9.7, the failure occurs
> immediately when it tries to download the JavaFX dependencies.
>
> 2021-12-27
> JDK-8279380: Duplicate profile id in JavaFX maven POM
> https://bugs.openjdk.org/browse/JDK-8279380
>
> 2022-12-22
> JDK-8299352: Duplicate profile id in JavaFX maven POM
> https://bugs.openjdk.org/browse/JDK-8299352
>
> 2023-03-24
> JDK-8305167: Duplicate profile ids in generated javafx-19.0.2.1.pom
> https://bugs.openjdk.org/browse/JDK-8305167
>
> Those three bugs were closed as duplicates of the following:
>
> 2021-12-23
> JDK-8279327: Maven Assembly Plugin Issues Warnings for JavaFx 17 Onwards
> https://bugs.openjdk.org/browse/JDK-8279327
>
> Comments in that bug report suggest reporting the issue to the JavaFX
> Maven Plugin project, but I'm getting the error, and I don't use that
> plugin. I also don't use the Maven Assembly Plugin.
>
> The Maven developers tell me the error is in the JavaFX parent POM file
> itself. Is that published by Gluon? So far I've been unable to produce
> the Maven artifacts using tasks in the JavaFX Gradle build file.
>
> Thanks,
> John
>

RFR: 8332748: Grammatical errors in animation API docs

[Lukasz Kostyra]

Checked code and fixed the gramatical error in Transition files: 
s/interval/intervals

Fill and Stroke Transition had correct grammatical form already, so those were 
untouched. I couldn't find any other instances of this error in our javadoc 
documentation.

-

Commit messages:
 - Fix gramatical errors in Transition javadoc comments

Changes: https://git.openjdk.org/jfx/pull/1466/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx=1466=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332748
  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1466.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1466/head:pull/1466

PR: https://git.openjdk.org/jfx/pull/1466