date:20240430

On Sat, 9 Mar 2024 18:41:10 GMT, Marius Hanl  wrote:

>> This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` 
>> is broken when `sizeToScene()` was called before or after.
>> 
>> The approach here is to ignore the `sizeToScene()` request when the `Stage` 
>> is maximized or set to fullscreen. 
>> Otherwise the Window Manager of the OS will be confused and you will get 
>> weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' 
>> button still shows the 'Restore' Icon, while we already resized the `Stage` 
>> to not be maximized).
>
> Marius Hanl has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   improve tests

The fix looks good. The spec changes (updated javadocs) look good. Can you 
create the CSR for the spec change?

I have a couple overall comments:

* I wanted to verify different orders of operation, so I wrote a (manual) test 
program and attached it to the JBS bug. It covers the following cases:
* set ; sizeToScene ; show
* sizeToScene ; set ; show
* show ; set ; sizeToScene
* show ; sizeToScene ; set

I verified that the first 3 are broken today. All cases work with your fix. I 
think it might be a good idea to add automated tests for the different 
orderings.

* Please merge the latest master. Note that the calls to Util.shutdown in the 
tests must be fixed after this is done or they will no longer compile.

tests/system/src/test/java/test/javafx/stage/SizeToSceneFullscreenTest.java 
line 69:

> 67: @AfterAll
> 68: public static void teardown() {
> 69: Util.shutdown(stage);

You will need to remove the `stage` argument after you merge the latest master.

tests/system/src/test/java/test/javafx/stage/SizeToSceneMaximizeTest.java line 
69:

> 67: @AfterAll
> 68: public static void teardown() {
> 69: Util.shutdown(stage);

You will need to remove the `stage` argument after you merge the latest master.

-

PR Review: https://git.openjdk.org/jfx/pull/1382#pullrequestreview-2032228167
PR Review Comment: https://git.openjdk.org/jfx/pull/1382#discussion_r1585330069
PR Review Comment: https://git.openjdk.org/jfx/pull/1382#discussion_r1585330320

Re: RFR: 8325591: [Mac] DRAG_DONE reports null transferMode when destination is external [v4]

On Tue, 30 Apr 2024 18:51:24 GMT, Martin Fox  wrote:

>> At the end of a drag operation the Mac Glass code sends out a DRAG_DONE 
>> event using the operation mask tracked in the GlassDragSource to determine 
>> the final transfer mode. That mask is only updated when a window in the 
>> JavaFX app is the drop destination. If the drag moves to an external 
>> destination the mask is set to NONE. If the drag terminates in the external 
>> destination that NONE forms the basis of the transfer mode sent via the 
>> DRAG_DONE event.
>> 
>> At the very end of the drag the OS calls the NSDraggingSource 
>> (GlassDraggingSource) with the final drag operation. This PR issues the 
>> DRAG_DONE from that callback so it can get the final transfer mode correct 
>> for both internal and external destinations.
>
> Martin Fox has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Update to match coding standards

Marked as reviewed by kcr (Lead).

-

PR Review: https://git.openjdk.org/jfx/pull/1371#pullrequestreview-2032469234

Re: RFR: 8325591: [Mac] DRAG_DONE reports null transferMode when destination is external [v4]

On Thu, 28 Mar 2024 12:53:24 GMT, Lukasz Kostyra  wrote:

>> Martin Fox has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Update to match coding standards
>
> LGTM

@lukostyra Can you please re-review?

-

PR Comment: https://git.openjdk.org/jfx/pull/1371#issuecomment-2087148313

Integrated: 8331319: IME Window breaks after popup menu

On Tue, 30 Apr 2024 14:52:50 GMT, Martin Fox  wrote:

> When focus moves away from a node JavaFX calls `finishInputMethodComposition` 
> so glass can clean up any in-progress IME editing. On Mac we call 
> `discardMarkedText` on the view's NSTextInputContext to dismiss the IME.
> 
> It appears that the OS can get confused if `discardMarkedText` is called on 
> an NSTextInputContext that is not the current active context. JavaFX popups 
> are displayed in windows that don't have OS focus and therefore do not have 
> the active input context but the JavaFX scene associated with the popup 
> doesn't know this and still makes calls to manipulate the IME. This seems to 
> be triggering a bug in the OS that leads to bad behavior which persists until 
> the user moves focus away from the main JavaFX stage altogether and then 
> brings it back.

This pull request has now been integrated.

Changeset: cac81b52
Author:Martin Fox 
URL:   
https://git.openjdk.org/jfx/commit/cac81b52fdeca763f3da21523c1582af3407aaf3
Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8331319: IME Window breaks after popup menu

Reviewed-by: kcr, angorya

-

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

Re: RFR: 8329820: [Linux] Prefer EGL over GLX [v8]

On Tue, 30 Apr 2024 20:03:18 GMT, Thiago Milczarek Sayao  
wrote:

>> Wayland implementation will require EGL. 
>> 
>> EGL works with Xorg as well. The idea is to be EGL first and if it fails, 
>> fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
>> 
>> 
>> See:
>> [Switching the Linux graphics stack from GLX to 
>> EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
>> [Prefer EGL to GLX for the GL support on 
>> X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)
>
> Thiago Milczarek Sayao has updated the pull request incrementally with four 
> additional commits since the last revision:
> 
>  - Rollback file
>  - rollback file
>  - - Rollback EGL_DEFAULT_DISPLAY
>- Don't trust eglGetDisplay without platform
>- Rollback Use PBuffer as the dummy surface
>  - Revert "- Use EGL_DEFAULT_DISPLAY"
>
>This reverts commit 0c78b7490aae221b8441028323bdfa7803e6252e.

I changed it to use platform specific way to get `EGLDisplay` so 
`eglGetDisplay` does not have to guess the platform (it can guess wrong).

It can be seen by setting `EGL_LOG_LEVEL=debug` (with `eglGetDisplay` it will 
output the guessing part).

I also reverted the Dummy window code change.

-

PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2087018281

Re: RFR: 8329820: [Linux] Prefer EGL over GLX [v8]

> Wayland implementation will require EGL. 
> 
> EGL works with Xorg as well. The idea is to be EGL first and if it fails, 
> fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
> 
> 
> See:
> [Switching the Linux graphics stack from GLX to 
> EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
> [Prefer EGL to GLX for the GL support on 
> X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)

Thiago Milczarek Sayao has updated the pull request incrementally with four 
additional commits since the last revision:

 - Rollback file
 - rollback file
 - - Rollback EGL_DEFAULT_DISPLAY
   - Don't trust eglGetDisplay without platform
   - Rollback Use PBuffer as the dummy surface
 - Revert "- Use EGL_DEFAULT_DISPLAY"
   
   This reverts commit 0c78b7490aae221b8441028323bdfa7803e6252e.

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1381/files
  - new: https://git.openjdk.org/jfx/pull/1381/files/0c78b749..619ae9c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1381&range=07
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1381&range=06-07

  Stats: 115 lines in 11 files changed: 52 ins; 29 del; 34 mod
  Patch: https://git.openjdk.org/jfx/pull/1381.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1381/head:pull/1381

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

Re: RFR: 8331319: IME Window breaks after popup menu

On Tue, 30 Apr 2024 14:52:50 GMT, Martin Fox  wrote:

> When focus moves away from a node JavaFX calls `finishInputMethodComposition` 
> so glass can clean up any in-progress IME editing. On Mac we call 
> `discardMarkedText` on the view's NSTextInputContext to dismiss the IME.
> 
> It appears that the OS can get confused if `discardMarkedText` is called on 
> an NSTextInputContext that is not the current active context. JavaFX popups 
> are displayed in windows that don't have OS focus and therefore do not have 
> the active input context but the JavaFX scene associated with the popup 
> doesn't know this and still makes calls to manipulate the IME. This seems to 
> be triggering a bug in the OS that leads to bad behavior which persists until 
> the user moves focus away from the main JavaFX stage altogether and then 
> brings it back.

ship it!

-

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1447#pullrequestreview-2032245187

Re: RFR: 8325591: [Mac] DRAG_DONE reports null transferMode when destination is external [v4]

> At the end of a drag operation the Mac Glass code sends out a DRAG_DONE event 
> using the operation mask tracked in the GlassDragSource to determine the 
> final transfer mode. That mask is only updated when a window in the JavaFX 
> app is the drop destination. If the drag moves to an external destination the 
> mask is set to NONE. If the drag terminates in the external destination that 
> NONE forms the basis of the transfer mode sent via the DRAG_DONE event.
> 
> At the very end of the drag the OS calls the NSDraggingSource 
> (GlassDraggingSource) with the final drag operation. This PR issues the 
> DRAG_DONE from that callback so it can get the final transfer mode correct 
> for both internal and external destinations.

Martin Fox has updated the pull request incrementally with one additional 
commit since the last revision:

  Update to match coding standards

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1371/files
  - new: https://git.openjdk.org/jfx/pull/1371/files/4eed575a..e2052e9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1371&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1371&range=02-03

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

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

Re: RFR: 8325591: [Mac] DRAG_DONE reports null transferMode when destination is external [v3]

On Tue, 30 Apr 2024 17:42:22 GMT, Martin Fox  wrote:

>> At the end of a drag operation the Mac Glass code sends out a DRAG_DONE 
>> event using the operation mask tracked in the GlassDragSource to determine 
>> the final transfer mode. That mask is only updated when a window in the 
>> JavaFX app is the drop destination. If the drag moves to an external 
>> destination the mask is set to NONE. If the drag terminates in the external 
>> destination that NONE forms the basis of the transfer mode sent via the 
>> DRAG_DONE event.
>> 
>> At the very end of the drag the OS calls the NSDraggingSource 
>> (GlassDraggingSource) with the final drag operation. This PR issues the 
>> DRAG_DONE from that callback so it can get the final transfer mode correct 
>> for both internal and external destinations.
>
> Martin Fox has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Fixed whitespace errors

Looks good. Thanks for the new manual test program. I left one minor formatting 
comment on the test, but I'll approve it anyway (and reapprove if you update 
it).

tests/manual/dnd/DndBasic.java line 169:

> 167: 
> 168: private Group createTarget(TransferMode[] modes)
> 169: {

Minor: move brace to previous line

-

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1371#pullrequestreview-2032195751
PR Review Comment: https://git.openjdk.org/jfx/pull/1371#discussion_r1585313426

Integrated: 8314215: Trailing Spaces before Line Breaks Affect the Center Alignment of Text

2024-04-30 Thread John Hendrikx

On Sun, 10 Sep 2023 20:50:18 GMT, John Hendrikx  wrote:

> There are a number of tickets open related to text rendering:
> 
> https://bugs.openjdk.org/browse/JDK-8314215
> 
> https://bugs.openjdk.org/browse/JDK-8145496
> 
> https://bugs.openjdk.org/browse/JDK-8129014
> 
> They have in common that wrapped text is taking the trailing spaces on each 
> wrapped line into account when calculating where to wrap.  This looks okay 
> for text that is left aligned (as the spaces will be trailing the lines and 
> generally aren't a problem, but looks weird with CENTER and RIGHT alignments. 
>  Even with LEFT alignment there are artifacts of this behavior, where a line 
> like `AAA  BBB  CCC` (note the **double** spaces) gets split up into `AAA  `, 
> `BBB  ` and `CCC`, but if space reduces further, it will wrap **too** early 
> because the space is taken into account (ie. `AAA` may still have fit just 
> fine, but `AAA  ` doesn't, so the engine wraps it to `AA` + `A  ` or 
> something).
> 
> The fix for this is two fold; first the individual lines of text should not 
> include any trailing spaces into their widths; second, the code that is 
> taking the trailing space into account when wrapping should ignore all 
> trailing spaces (currently it is ignoring all but one trailing space).  With 
> these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, 
> and there is no more early wrapping due to a space being taking into account 
> while the actual text still would have fit (this is annoying in tight 
> layouts, where a line can be wrapped early even though it looks like it would 
> have fit).
> 
> If it were that simple, we'd be done, but there may be another issue here 
> that needs solving: wrapped aligned TextArea's.
> 
> TextArea don't directly support text alignment (via a setTextAlignment method 
> like Label) but you can change it via CSS.
> 
> For Left alignment + wrapping, TextArea will ignore any spaces typed before a 
> line that was wrapped.  In other words, you can type spaces as much as you 
> want, and they won't show up and the cursor won't move.  The spaces are all 
> getting appended to the previous line.  When you cursor through these spaces, 
> the cursor can be rendered out of the control's bounds.  To illustrate, if 
> you have the text `AAA BBB CCC`, and the text gets wrapped to 
> `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up.  If you 
> cursor back, the cursor may be outside the control bounds because so many 
> spaces are trailing `AAA`.
> 
> The above behavior has NOT changed, is pretty standard for wrapped text 
> controls, and IMHO does not need further attent...

This pull request has now been integrated.

Changeset: 398f104d
Author:John Hendrikx 
URL:   
https://git.openjdk.org/jfx/commit/398f104d6ba721f4534d6e7afdc903b2384e147f
Stats: 1011 lines in 7 files changed: 762 ins; 231 del; 18 mod

8314215: Trailing Spaces before Line Breaks Affect the Center Alignment of Text

Reviewed-by: kpk, angorya

-

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

Re: RFR: 8331319: IME Window breaks after popup menu

On Tue, 30 Apr 2024 14:52:50 GMT, Martin Fox  wrote:

> When focus moves away from a node JavaFX calls `finishInputMethodComposition` 
> so glass can clean up any in-progress IME editing. On Mac we call 
> `discardMarkedText` on the view's NSTextInputContext to dismiss the IME.
> 
> It appears that the OS can get confused if `discardMarkedText` is called on 
> an NSTextInputContext that is not the current active context. JavaFX popups 
> are displayed in windows that don't have OS focus and therefore do not have 
> the active input context but the JavaFX scene associated with the popup 
> doesn't know this and still makes calls to manipulate the IME. This seems to 
> be triggering a bug in the OS that leads to bad behavior which persists until 
> the user moves focus away from the main JavaFX stage altogether and then 
> brings it back.

With jfx21-ea+12, I see the same incorrect font, so it must be a different 
issue.


java --module-path "REDACTED/Java/javafx-sdk-21/lib" --add-modules 
javafx.base,javafx.graphics,javafx.controls,javafx.swing,javafx.web -jar 
"REDACTED/MonkeyTest2/MonkeyTest/dist/MonkeyTester.jar"

-

PR Comment: https://git.openjdk.org/jfx/pull/1447#issuecomment-2086266422

Re: RFR: 8325591: [Mac] DRAG_DONE reports null transferMode when destination is external [v3]

> At the end of a drag operation the Mac Glass code sends out a DRAG_DONE event 
> using the operation mask tracked in the GlassDragSource to determine the 
> final transfer mode. That mask is only updated when a window in the JavaFX 
> app is the drop destination. If the drag moves to an external destination the 
> mask is set to NONE. If the drag terminates in the external destination that 
> NONE forms the basis of the transfer mode sent via the DRAG_DONE event.
> 
> At the very end of the drag the OS calls the NSDraggingSource 
> (GlassDraggingSource) with the final drag operation. This PR issues the 
> DRAG_DONE from that callback so it can get the final transfer mode correct 
> for both internal and external destinations.

Martin Fox has updated the pull request incrementally with one additional 
commit since the last revision:

  Fixed whitespace errors

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1371/files
  - new: https://git.openjdk.org/jfx/pull/1371/files/c0bbbf5c..4eed575a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1371&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1371&range=01-02

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

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

Re: RFR: 8325591: [Mac] DRAG_DONE reports null transferMode when destination is external [v2]

> At the end of a drag operation the Mac Glass code sends out a DRAG_DONE event 
> using the operation mask tracked in the GlassDragSource to determine the 
> final transfer mode. That mask is only updated when a window in the JavaFX 
> app is the drop destination. If the drag moves to an external destination the 
> mask is set to NONE. If the drag terminates in the external destination that 
> NONE forms the basis of the transfer mode sent via the DRAG_DONE event.
> 
> At the very end of the drag the OS calls the NSDraggingSource 
> (GlassDraggingSource) with the final drag operation. This PR issues the 
> DRAG_DONE from that callback so it can get the final transfer mode correct 
> for both internal and external destinations.

Martin Fox 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:

 - Added manual test that covers all the DnD basics
 - Merge remote-tracking branch 'upstream/master' into macdropop
 - Using OS to determine DRAG_DONE operation

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1371/files
  - new: https://git.openjdk.org/jfx/pull/1371/files/4f088cc3..c0bbbf5c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1371&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1371&range=00-01

  Stats: 32641 lines in 1003 files changed: 17817 ins; 6536 del; 8288 mod
  Patch: https://git.openjdk.org/jfx/pull/1371.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1371/head:pull/1371

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

Re: RFR: 8330590: TextInputControl: previous word fails with Bhojpuri characters [v2]

2024-04-30 Thread Karthik P K

On Mon, 29 Apr 2024 21:27:41 GMT, Andy Goryachev  wrote:

> If I were to fix the behavior (if we decide to fix the behavior of the 
> nextWord function, that is), I would make it consistent with MS Word, but 
> let's discuss.
> 
The behaviour in MS word looks to be easy to understand and what we would 
expect. +1 for this.

Thanks @andy-goryachev-oracle for checking the behaviour and providing the 
details.

-

PR Comment: https://git.openjdk.org/jfx/pull/1444#issuecomment-2086045856

Re: RFR: 8330590: TextInputControl: previous word fails with Bhojpuri characters [v2]

On Tue, 30 Apr 2024 17:11:25 GMT, Karthik P K  wrote:

>> Looking at the "next word" functionality across different applications on 
>> different platforms, it appears to be a wide variety of behaviors.
>> 
>> One vendor appears to be quite consistent - Microsoft.  Its word, word pad, 
>> notepad work exactly the same, with Word working the same across macOS and 
>> Win11.
>> 
>> JavaFX TextArea is inconsistent (by design) between macOS and Win11, but 
>> also is inconsistent with Swing's JTextArea.
>> 
>> If I were to fix the behavior (if we decide to fix the behavior of the 
>> nextWord function, that is), I would make it consistent with MS Word, but 
>> let's discuss.
>> 
>> For reference, here is the result of my testing.  Initially, the caret is 
>> placed at index 0 and the numbers in parentheses denote successive caret 
>> positions after ctrl-RIGHT (option-RIGHT) key presses.  An underline denotes 
>> a space, and a (nl) denotes a newline.
>> 
>> 
>> source
>> _english_english_eng:_end,_eng:_(nl)
>> (nl)
>> _eng
>> 
>> 
>> BreakIterator.getWordInstance()
>> _(1)english(2)_(3)english(4)_(5)eng(6):(7)_(8)end(9),(10)_(11)eng(12):(13)_(14)(nl)
>> (15)(nl)
>> (16)_(17)eng
>> 
>> 
>> text area (mac)
>> _english(1)_english(2)_eng(3):(4)_end(5),(6)_eng(7):(8)_(nl)
>> (9)(nl)
>> (10)_eng(11)
>> 
>> 
>> ms word (mac) 16.84 24041420 consistent with win11
>> _(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
>> (10)(nl)
>> (11)_(12)eng(13)
>> 
>> 
>> text edit (mac)
>> _english(1)_english(2)_eng(3):_end(4),_eng(5):_(nl)
>> (nl)
>> (nl)_eng(6)
>> 
>> 
>> chrome (mac) 
>>  english(1)_english(2)_eng(3):(4)_end(5),(6)_eng(7):(8)_
>> (9)
>> _(10)eng(11)
>> 
>> 
>> eclipse (mac)
>> _(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
>> (10)(nl)
>> (11)_(12)eng
>> 
>> 
>> JTextArea (mac)
>> _(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
>> (nl)
>> _(10)eng
>> 
>> 
>> ms word 365 ver 2302 build 16.0.16130.20942 (win 11)
>> same as notepad (win 11)
>> same as wordpad (win 11)
>> _(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
>> (10)(nl)
>> (11)_(12)eng
>> 
>> 
>> TextArea (win11)
>> _(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
>> (10)(nl)
>> _(11)eng
>
>> If I were to fix the behavior (if we decide to fix the behavior of the 
>> nextWord function, that is), I would make it consistent with MS Word, but 
>> let's discuss.
>> 
> The behaviour in MS word looks to be easy to understand and what we would 
> expect. +1 for this.
> 
> Thanks @andy-goryachev-oracle for checking the behaviour and providing the 
> details.

thank you @karthikpandelu for raising the question!

-

PR Comment: https://git.openjdk.org/jfx/pull/1444#issuecomment-2086058099

Re: RFR: 8331319: IME Window breaks after popup menu

On Tue, 30 Apr 2024 14:52:50 GMT, Martin Fox  wrote:

> When focus moves away from a node JavaFX calls `finishInputMethodComposition` 
> so glass can clean up any in-progress IME editing. On Mac we call 
> `discardMarkedText` on the view's NSTextInputContext to dismiss the IME.
> 
> It appears that the OS can get confused if `discardMarkedText` is called on 
> an NSTextInputContext that is not the current active context. JavaFX popups 
> are displayed in windows that don't have OS focus and therefore do not have 
> the active input context but the JavaFX scene associated with the popup 
> doesn't know this and still makes calls to manipulate the IME. This seems to 
> be triggering a bug in the OS that leads to bad behavior which persists until 
> the user moves focus away from the main JavaFX stage altogether and then 
> brings it back.

same issue without the fix.  I agree - this is likely unrelated.

I won't be able to try with an earlier jdk in the next couple of hours, sorry.

-

PR Comment: https://git.openjdk.org/jfx/pull/1447#issuecomment-2085695130

Re: RFR: 8331319: IME Window breaks after popup menu

On Tue, 30 Apr 2024 14:52:50 GMT, Martin Fox  wrote:

> When focus moves away from a node JavaFX calls `finishInputMethodComposition` 
> so glass can clean up any in-progress IME editing. On Mac we call 
> `discardMarkedText` on the view's NSTextInputContext to dismiss the IME.
> 
> It appears that the OS can get confused if `discardMarkedText` is called on 
> an NSTextInputContext that is not the current active context. JavaFX popups 
> are displayed in windows that don't have OS focus and therefore do not have 
> the active input context but the JavaFX scene associated with the popup 
> doesn't know this and still makes calls to manipulate the IME. This seems to 
> be triggering a bug in the OS that leads to bad behavior which persists until 
> the user moves focus away from the main JavaFX stage altogether and then 
> brings it back.

That seems likely a different issue. Can you try it with a build without the 
current PR? And maybe also try it with JavaFX 22 to rule out other 
recently-introduced problems?

-

PR Comment: https://git.openjdk.org/jfx/pull/1447#issuecomment-2085676916

Re: RFR: 8331319: IME Window breaks after popup menu

On Tue, 30 Apr 2024 14:52:50 GMT, Martin Fox  wrote:

> When focus moves away from a node JavaFX calls `finishInputMethodComposition` 
> so glass can clean up any in-progress IME editing. On Mac we call 
> `discardMarkedText` on the view's NSTextInputContext to dismiss the IME.
> 
> It appears that the OS can get confused if `discardMarkedText` is called on 
> an NSTextInputContext that is not the current active context. JavaFX popups 
> are displayed in windows that don't have OS focus and therefore do not have 
> the active input context but the JavaFX scene associated with the popup 
> doesn't know this and still makes calls to manipulate the IME. This seems to 
> be triggering a bug in the OS that leads to bad behavior which persists until 
> the user moves focus away from the main JavaFX stage altogether and then 
> brings it back.

Seems to work with the little test program.

Observed a weird behavior in the Monkey Tester
https://github.com/andy-goryachev-oracle/MonkeyTest

- open TextArea page
- set font to System Regular
- select text: "Writing Systems"
- click on any English word, invoke IME (I use Japanese), observe candidate 
inserted correctly
- click on non-English word, invoke IME, the candidate is still shows up 
correctly
- click on an English word, invoke IME and the candidate shows garbage.  

It seems to me it might be using font from the previous invocation?
This could be a different issue though.

![Screenshot 2024-04-30 at 08 18 
55](https://github.com/openjdk/jfx/assets/107069028/9435df5d-18e4-4aa4-88bd-a42fee0811cf)

-

PR Comment: https://git.openjdk.org/jfx/pull/1447#issuecomment-2085670379

Re: RFR: 8331319: IME Window breaks after popup menu

On Tue, 30 Apr 2024 14:52:50 GMT, Martin Fox  wrote:

> When focus moves away from a node JavaFX calls `finishInputMethodComposition` 
> so glass can clean up any in-progress IME editing. On Mac we call 
> `discardMarkedText` on the view's NSTextInputContext to dismiss the IME.
> 
> It appears that the OS can get confused if `discardMarkedText` is called on 
> an NSTextInputContext that is not the current active context. JavaFX popups 
> are displayed in windows that don't have OS focus and therefore do not have 
> the active input context but the JavaFX scene associated with the popup 
> doesn't know this and still makes calls to manipulate the IME. This seems to 
> be triggering a bug in the OS that leads to bad behavior which persists until 
> the user moves focus away from the main JavaFX stage altogether and then 
> brings it back.

Looks good. I verified on my macOS 13.6.6 system that this fixes the problem. I 
also verified that the test program from JDK-8320912 still works correctly.

-

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1447#pullrequestreview-2031686652

Re: RFR: 8331319: IME Window breaks after popup menu

On Tue, 30 Apr 2024 14:52:50 GMT, Martin Fox  wrote:

> When focus moves away from a node JavaFX calls `finishInputMethodComposition` 
> so glass can clean up any in-progress IME editing. On Mac we call 
> `discardMarkedText` on the view's NSTextInputContext to dismiss the IME.
> 
> It appears that the OS can get confused if `discardMarkedText` is called on 
> an NSTextInputContext that is not the current active context. JavaFX popups 
> are displayed in windows that don't have OS focus and therefore do not have 
> the active input context but the JavaFX scene associated with the popup 
> doesn't know this and still makes calls to manipulate the IME. This seems to 
> be triggering a bug in the OS that leads to bad behavior which persists until 
> the user moves focus away from the main JavaFX stage altogether and then 
> brings it back.

Reviewers: @andy-goryachev-oracle @kevinrushforth

-

PR Comment: https://git.openjdk.org/jfx/pull/1447#issuecomment-2085565591

RFR: 8331319: IME Window breaks after popup menu

When focus moves away from a node JavaFX calls `finishInputMethodComposition` 
so glass can clean up any in-progress IME editing. On Mac we call 
`discardMarkedText` on the view's NSTextInputContext to dismiss the IME.

It appears that the OS can get confused if `discardMarkedText` is called on an 
NSTextInputContext that is not the current active context. JavaFX popups are 
displayed in windows that don't have OS focus and therefore do not have the 
active input context but the JavaFX scene associated with the popup doesn't 
know this and still makes calls to manipulate the IME. This seems to be 
triggering a bug in the OS that leads to bad behavior which persists until the 
user moves focus away from the main JavaFX stage altogether and then brings it 
back.

-

Commit messages:
 - Check that input context is active before calling discardMarkedText

Changes: https://git.openjdk.org/jfx/pull/1447/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1447&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331319
  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1447.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1447/head:pull/1447

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

Re: RFR: 8329820: [Linux] Prefer EGL over GLX [v7]

On Tue, 30 Apr 2024 12:22:34 GMT, Thiago Milczarek Sayao  
wrote:

>> Wayland implementation will require EGL. 
>> 
>> EGL works with Xorg as well. The idea is to be EGL first and if it fails, 
>> fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
>> 
>> 
>> See:
>> [Switching the Linux graphics stack from GLX to 
>> EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
>> [Prefer EGL to GLX for the GL support on 
>> X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   - Use EGL_DEFAULT_DISPLAY
>   - Deallocate the resources correctly
>   - Use PBuffer as the dummy surface

I'll have to fix it

I got a reply explaining it (the docs where not very clear)
https://lists.freedesktop.org/archives/mesa-users/2024-April/001727.html

-

PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2085554001

Re: RFR: 8329820: [Linux] Prefer EGL over GLX [v7]

On Tue, 30 Apr 2024 12:22:34 GMT, Thiago Milczarek Sayao  
wrote:

>> Wayland implementation will require EGL. 
>> 
>> EGL works with Xorg as well. The idea is to be EGL first and if it fails, 
>> fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
>> 
>> 
>> See:
>> [Switching the Linux graphics stack from GLX to 
>> EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
>> [Prefer EGL to GLX for the GL support on 
>> X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   - Use EGL_DEFAULT_DISPLAY
>   - Deallocate the resources correctly
>   - Use PBuffer as the dummy surface

It is possible to set the platform with `EGL_PLATFORM=x11` environment 
variable. 
Using ` EGL_LOG_LEVEL=debug ` currently outputs that the platform was detected 
in build time - I think it's wrong.

-

PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2085427160

Re: [External] : Re: Wayland

Thanks.

-- Kevin

On 4/30/2024 6:41 AM, Thiago Milczarek Sayão wrote:

Hi,

I rewrote the scanner, so it's all my own code now. No legal issues
since I signed the OCA.

Generated java code looks like this:
https://github.com/tsayao/glass-wayland/blob/main/src/com/sun/glass/wayland/extracted/XdgToplevel.java

-- Thiago.

Em seg., 29 de abr. de 2024 às 19:57, Kevin Rushforth
escreveu:

Thank you.

-- Kevin

On 4/29/2024 2:35 PM, Thiago Milczarek Sayão wrote:

I thought about possible legal conflicts.

The code is on my github - I'm exploring and testing before
starting the real work.

wayland-scanner generates code from the protocol specs, which are
xml files.
https://wayland.app/protocols/

I will write a new generator/scanner from scratch - it's not too
much work.
The generator/scanner itself does not necessarily need to be part
of the PR, but it might be a good idea to include it, since the
protocol changes over time.

-- Thiago.

Em seg., 29 de abr. de 2024 às 18:10, Kevin Rushforth
escreveu:

As a reminder, contributors must not include 3rd-party code
in any openjdk repo. Per the terms of the OCA, all code that
you contribute to OpenJDK must be your own code. This
includes code you push to openjdk/jfx-sandbox and code in a
branch of a personal fork of openjdk/jfx from which you
create a PR.

-- Kevin

On 4/28/2024 2:45 PM, Thiago Milczarek Sayão wrote:

Hi,

I managed to display a very basic wayland toplevel surface
from java:
https://github.com/tsayao/glass-wayland

If you are using intellij, just run the "Test App" (with
java 22).

generate.sh will jextract the code from wayland-client.

I rushed to get the window displayed - so it doesn't look
good yet (but I do accept suggestions).

It uses a java wayland-scanner (included) to read protocol
xml files and generate code that uses jextracted calls.

The sample also binds EGL and GL apis, but just because
wayland requires a buffer to display the surface. Maybe it
was easier to use a shared memory :)

Credits to (I adapted it to ouput jextract compatible code):
https://github.com/gfxstrand/wayland-java/tree/master/scanner

Cheers

Em ter., 23 de abr. de 2024 às 09:11, Thiago Milczarek Sayão
escreveu:

I'm doing some work here:
https://github.com/tsayao/glass-wayland

So far it's been a good experience to use FFM / jextract.

The idea is to plug it as a glass wayland backend when
it's good enough.

Em seg., 22 de abr. de 2024 às 16:16, Nir Lisker
escreveu:

Not sure it helps with warmup, but marking a foreign
function as critical can improve performance:

https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/Linker.Option.html#critical(boolean).

On Mon, Apr 22, 2024 at 10:02 PM Philip Race
wrote:

No, it wasn't. I didn't even use jextracted code.
The startup cost is around initialisation of FFM
- around 70 ms (IIRC) overhead on my MacBook
Then creation of VarHandles and MethodHandles -
2-5 ms each is what I measured, so do these
lazily if you can.
And warmup cost is that it takes about 1
iterations to get code fully compiled.

java -XX:+PrintFlagsFinal -version 2>&1 | grep
CompileThreshold
intx CompileThreshold = 1 {pd product}
{default}
double CompileThresholdScaling = 1.00
{product} {default}
uintx IncreaseFirstTierCompileThresholdAt =
50 {product} {default}
intx Tier2CompileThreshold = 0 {product}
{default}

Re: [External] : Re: Wayland

2024-04-30 Thread Thiago Milczarek Sayão

Hi,

I rewrote the scanner, so it's all my own code now. No legal issues since I
signed the OCA.

Generated java code looks like this:
https://github.com/tsayao/glass-wayland/blob/main/src/com/sun/glass/wayland/extracted/XdgToplevel.java


-- Thiago.

Em seg., 29 de abr. de 2024 às 19:57, Kevin Rushforth <
kevin.rushfo...@oracle.com> escreveu:

> Thank you.
>
> -- Kevin
>
>
> On 4/29/2024 2:35 PM, Thiago Milczarek Sayão wrote:
>
> I thought about possible legal conflicts.
>
> The code is on my github - I'm exploring and testing before starting the
> real work.
>
> wayland-scanner generates code from the protocol specs, which are xml
> files.
> https://wayland.app/protocols/
> 
>
> I will write a new generator/scanner from scratch - it's not too much
> work.
> The generator/scanner itself does not necessarily need to be part of the
> PR, but it might be a good idea to include it, since the protocol changes
> over time.
>
> -- Thiago.
>
>
>
> Em seg., 29 de abr. de 2024 às 18:10, Kevin Rushforth <
> kevin.rushfo...@oracle.com> escreveu:
>
>> As a reminder, contributors must not include 3rd-party code in any
>> openjdk repo. Per the terms of the OCA, all code that you contribute to
>> OpenJDK must be your own code. This includes code you push to
>> openjdk/jfx-sandbox and code in a branch of a personal fork of openjdk/jfx
>> from which you create a PR.
>>
>> -- Kevin
>>
>>
>> On 4/28/2024 2:45 PM, Thiago Milczarek Sayão wrote:
>>
>> Hi,
>>
>> I managed to display a very basic wayland toplevel surface from java:
>> https://github.com/tsayao/glass-wayland
>> 
>>
>> If you are using intellij, just run the "Test App" (with java 22).
>>
>> generate.sh will jextract the code from wayland-client.
>>
>> I rushed to get the window displayed - so it doesn't look good yet (but I
>> do accept suggestions).
>>
>> It uses a java wayland-scanner (included) to read protocol xml files and
>> generate code that uses jextracted calls.
>>
>> The sample also binds EGL and GL apis, but just because wayland requires
>> a buffer to display the surface. Maybe it was easier to use a shared memory
>> :)
>>
>> Credits to (I adapted it to ouput jextract compatible code):
>> https://github.com/gfxstrand/wayland-java/tree/master/scanner
>> 
>>
>> Cheers
>>
>> Em ter., 23 de abr. de 2024 às 09:11, Thiago Milczarek Sayão <
>> thiago.sa...@gmail.com> escreveu:
>>
>>> I'm doing some work here:
>>> https://github.com/tsayao/glass-wayland
>>> 
>>>
>>> So far it's been a good experience to use FFM / jextract.
>>>
>>> The idea is to plug it as a glass wayland backend when it's good enough.
>>>
>>>
>>>
>>> Em seg., 22 de abr. de 2024 às 16:16, Nir Lisker 
>>> escreveu:
>>>
 Not sure it helps with warmup, but marking a foreign function as
 critical can improve performance:
 https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/Linker.Option.html#critical(boolean)
 .

 On Mon, Apr 22, 2024 at 10:02 PM Philip Race 
 wrote:

> No, it wasn't. I didn't even use jextracted code.
> The startup cost is around initialisation of FFM - around 70 ms (IIRC)
> overhead on my MacBook
> Then creation of VarHandles and MethodHandles - 2-5 ms each is what I
> measured, so do these lazily if you can.
> And warmup cost is that it takes about 1 iterations to get code
> fully compiled.
>
> java -XX:+PrintFlagsFinal -version 2>&1 | grep CompileThreshold
>  intx CompileThreshold =
> 1  {pd product} {default}
> double CompileThresholdScaling  =
> 1.00  {product} {default}
> uintx IncreaseFirstTierCompileThresholdAt  =
> 50{product} {default}
>  intx Tier2CompileThreshold=
> 0 {product} {default}
>  intx Tier3CompileThreshold=
> 2000  {product} {default}
>  intx Tier4CompileThreshold=
> 15000 {product} {default}
>
> -phil.
>
>
> On 4/22/24 1

Re: RFR: 8329820: [Linux] Prefer EGL over GLX [v7]

On Tue, 30 Apr 2024 12:22:34 GMT, Thiago Milczarek Sayao  
wrote:

>> Wayland implementation will require EGL. 
>> 
>> EGL works with Xorg as well. The idea is to be EGL first and if it fails, 
>> fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
>> 
>> 
>> See:
>> [Switching the Linux graphics stack from GLX to 
>> EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
>> [Prefer EGL to GLX for the GL support on 
>> X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   - Use EGL_DEFAULT_DISPLAY
>   - Deallocate the resources correctly
>   - Use PBuffer as the dummy surface

I changed it to use EGL_DEFAULT_DISPLAY in a attempt to make no assumptions on 
the platform. It works, but I'm not sure if it's correct. I'm looking at Mesa 
egl source to be sure.

I also changed the dummy window to use PBUFFER (also to make no assumptions on 
the platform, so there's no need to create a XWindow). I'm also not sure about 
that.

-

PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2085214672

Re: RFR: 8329820: [Linux] Prefer EGL over GLX [v7]