Re: The crisp fonts saga

[John Hendrikx]

On 14/12/2023 07:15, John Neffenger wrote:

On 12/13/23 3:29 AM, Mark Raynsford wrote:


Can you give an example of UIs scaling unevenly, or animations looking
jerky? All other non-JavaFX UI applications on my system evidently use
hinting, and I don't see anything recognizable there.


There are some text animations in JavaFX that you won't see in most 
user interfaces: think text rotations, not stock tickers. It's 
difficult to keep text aligned to the pixel grid when the grid is 
rotating.


Animated text is extremely rare in productivity applications, so I think 
this really should be an option on a Node by Node basis (there is 
already the cache/cacheHint property which are animation related). A big 
wall of text (like in a rich text control, TextArea or some kind of text 
editor) shouldn't have to suffer in readability just in case we may want 
to rotate or scale it... If Browsers had the JavaFX mentality of font 
rendering, everyone would switch to the one browser that renders font 
properly -- and I can imagine poorly rendered text is one the first 
things people notice and can be a big reason for worse JavaFX adoption.


Also, if the animation is fast enough (ie,  a quick rotate / scale / 
translate transition) you won't notice any odd effects on the text 
scaling.  I can imagine it will look terrible though if you slow those 
down (ie. a transition taking a couple of seconds -- a bit unrealistic 
for a usable application though).


--John

Re: The crisp fonts saga

[Mark Raynsford]

On Thu, 2023-12-14 at 10:23 +0100, John Hendrikx wrote:
> 
> Animated text is extremely rare in productivity applications, so I
> think 
> this really should be an option on a Node by Node basis (there is 
> already the cache/cacheHint property which are animation related). A
> big 
> wall of text (like in a rich text control, TextArea or some kind of
> text 
> editor) shouldn't have to suffer in readability just in case we may
> want 
> to rotate or scale it... If Browsers had the JavaFX mentality of font
> rendering, everyone would switch to the one browser that renders font
> properly -- and I can imagine poorly rendered text is one the first 
> things people notice and can be a big reason for worse JavaFX
> adoption.

I agree strongly.

Purely anecdotally, and obviously I'm only a single sample point
(although there are two more lower down!): I started out as a classic
Mac user back in the early days of Mac OS 7. I migrated to Windows 2000
and Linux, and have primarily been a Linux user and to a drastically
lesser extent a Windows user for my entire career. I mention this
because I want to make it clear that I'm not biased towards any
particular style of text rendering.

I've worked on GTK, QT, and FLTK applications. Some small-scale Cocoa
applications when Mac OS X first appeared. I've written Windows
applications in the Win32 days. I've written Swing applications. All of
these have been used by others to varying degrees.

What's the _one_ platform where users complained about the text?
JavaFX. Worst is that there's really nothing I can tell them... "Sorry
the text is awful, the UI library I used has made the decision for me
and won't allow me to change it."

It's essentially my only complaint with JavaFX. In all other respects,
it's better than every other UI library I've ever used.

--
Mark Raynsford | https://www.io7m.com

Re: The crisp fonts saga

[Mark Raynsford]

On Wed, 2023-12-13 at 22:15 -0800, John Neffenger wrote:
>
> There are some text animations in JavaFX that you won't see in most
> user 
> interfaces: think text rotations, not stock tickers. It's difficult
> to 
> keep text aligned to the pixel grid when the grid is rotating.

I don't buy this argument, having looked at the implementation.

The key point is "keep text aligned to the pixel grid". The thing is:
This isn't affected by hinting or the lack of it whatsoever, at least
with the way text is implemented in Prism and Freetype, as far as I can
tell.

In the Prism/Freetype implementation, when the user wants to render the
string "Hello World!", for each character in the string, a glyph is
requested from Freetype. The contents of the returned glyph bitmap are
packed into a persistent texture atlas on the GPU (the "glyph cache").
When actually rendering the string in the UI, the system constructs a
set of polygons where each polygon represents one glyph, and each
polygon is textured by having its UV coordinates mapped to the
corresponding region of the glyph cache for the glyph.

What this means is that it's entirely irrelevant whether hinting is
used to produce the original glyph bitmap or not: The hinting just
controls what pixels come out of Freetype before being written into the
glyph cache. The system blindly selects a region of pixels from the
glyph cache to be mapped onto polygons; it doesn't even know if those
pixels were produced by a text rendering algorithm that used hinting or
not.

This argument _might_ apply if text was being directly software
rendered to the screen, and the entire text was being re-rendered as
full strings aligned to a screen-sized pixel grid every time. I could
see in that case that an algorithm might produce output that varied on
a frame-to-frame basis dependent on hinting. That's not the case here,
though.

Case in point: I've worked with a lot of OpenGL applications that do
text rendering the same way, all of which used hinting, and all of
which did heavy rotation and scaling of the resulting text as part of
animations. Noone ever complained about jerky or weird text. In fact,
most rendering engines these days don't even bother rendering text on a
per-glyph basis; they just tell Freetype (or text library of choice) to
render a full string into an image, with hinting, and that image is
uploaded directly onto the GPU and displayed as a single textured
polygon.

Additionally, there are also techniques devoted to preserving
sharpness and reducing other artifacts in the face of rotations.
They're known as "fat pixel" shaders, and are trivial to implement:

https://jorenjoestar.github.io/post/pixel_art_filtering/

They're usually discussed in the context of pixel art, but they work
very well with text rendering too for the same reasons.

-- 
Mark Raynsford | https://www.io7m.com

Re: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland

[Kevin Rushforth]

On Tue, 12 Dec 2023 11:19:23 GMT, Jose Pereda  wrote:

> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and 
> `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and 
> wrapped functions for GTK 3.20+ (so systems without it still run with GTK 
> 3.8+), and fixes the dragging issue on Wayland.

We want the ability to build this on a system that may or may not have GTK 
3.20, and then to have the binary produced by the build be able to run on a 
system that may or may not have GTK 3.20, using the new function if available.

This means that there should not be any compile-time `#if` checks. All checks 
should be runtime checks, for example, checking whether or not the function 
pointer obtained via dlsym is NULL vs non-NULL.

I think you already have the needed runtime checks. I was able to compile your 
PR branch, using headers and libraries from GTK > 3.20, and run it on a system 
with GTK < 3.20. I confirmed that the dlsym returned NULL on that system (as 
expected), and it didn't crash.

So it might be as simple as removing the `#if` checks along with the entire 
"else" blocks, letting the code currently in the `#if` checks be 
unconditionally compiled. As long as you aren't using anything from a system 
GTK header file that doesn't exist in 3.8, this should be fine.

modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp line 599:

> 597: return TRUE;
> 598: }
> 599: #if GTK_CHECK_VERSION(3, 20, 0)

I wouldn't have expected any compile-time `#if` checks as part of this PR.

-

PR Review: https://git.openjdk.org/jfx/pull/1305#pullrequestreview-1782152507
PR Review Comment: https://git.openjdk.org/jfx/pull/1305#discussion_r1426923806

Re: The crisp fonts saga

[John Neffenger]

On 12/12/23 6:10 AM, Mark Raynsford wrote:

I've never been particularly satisfied with the font rendering in
JavaFX. In particular, on Linux, the text always appears very soft and
blurry compared to non-JavaFX applications on the same system.


Here's the best source I've found for the history of JavaFX text 
rendering. It's a presentation by Felipe Heidrich who worked on the 
implementation and now works at Google.


JavaFX Text Rendering
https://www.youtube.com/watch?v=LCrCni6EVek

It's frustratingly short on details about the specific decision not to 
use hinting on Linux, but you can hear his opinions on the matter. In 
particular, see the following sections:


Text Rendering Options
https://www.youtube.com/watch?v=LCrCni6EVek&t=911

Hinting
https://www.youtube.com/watch?v=LCrCni6EVek&t=1607

Linux
https://www.youtube.com/watch?v=LCrCni6EVek&t=2716

In this part he says only, "Another thing you can do in Freetype, you 
can tell it not to hint."


My main point in my previous message was that, in the unlikely event 
that we were to apply hinting in JavaFX on Linux, I would hope that we 
use the "slight" hinting that is recommended by Freetype. That snaps to 
the pixel grid only vertically, preserving the inter-glyph spacing of 
horizontal text.


Kevin and Phil, were you working with Felipe when these text rendering 
decisions were made almost 10 years ago? Do you recall any background 
information on the design choices?


Thanks,
John

Re: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland

[Jose Pereda]

On Thu, 14 Dec 2023 16:02:48 GMT, Kevin Rushforth  wrote:

>> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and 
>> `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and 
>> wrapped functions for GTK 3.20+ (so systems without it still run with GTK 
>> 3.8+), and fixes the dragging issue on Wayland.
>
> modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp line 599:
> 
>> 597: return TRUE;
>> 598: }
>> 599: #if GTK_CHECK_VERSION(3, 20, 0)
> 
> I wouldn't have expected any compile-time `#if` checks as part of this PR.

Okay, that makes sense. 

I've removed the compile-time `#if-#else` from `wrapped.c`.

However, to do the same in `glass_general.cpp`, if the wrapped functions fail 
(when dlsym returns null), we still need to fall back to the old 
implementation, don't we? 

Therefore, I've changed the signature to return a `gboolean` (and removed the 
`GDK_GRAB_FAILED` enum value that was added in 3.16, as I just noticed).

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1305#discussion_r1427224949

Re: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v2]

[Jose Pereda]

> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and 
> `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and 
> wrapped functions for GTK 3.20+ (so systems without it still run with GTK 
> 3.8+), and fixes the dragging issue on Wayland.

Jose Pereda has updated the pull request incrementally with one additional 
commit since the last revision:

  remove compile-time if checks

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1305/files
  - new: https://git.openjdk.org/jfx/pull/1305/files/f498b835..99230ca6

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

  Stats: 32 lines in 3 files changed: 5 ins; 8 del; 19 mod
  Patch: https://git.openjdk.org/jfx/pull/1305.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1305/head:pull/1305

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

Re: ToggleButton behavior

[Martin Fox]

Hi Andy,

The Mozilla doc you pointed to basically re-iterates the W3C guidelines. When a 
ToggleButton is in a group it should behave like other grouped controls where 
Tab gets you into and out of the group and the arrow keys navigate within the 
group. I would still argue that an ungrouped ToggleButton should traverse like 
any other button.

I’m not familiar enough with JavaFX’s focus traversal implementation to have an 
opinion. Based on past experience I wouldn’t wade into those waters until I had 
a plan in place for how to validate the results. In my previous job we did a 
big accessibility push and ended up assigning one engineer whose primary job 
was liaising with accessibility tool vendors to make sure we got it right. She 
was worth her weight in gold. 

(Whatever happened to the issue where multiple nodes in a scene can set their 
focused property? As I recall someone on the controls side needed to dig in and 
figure out what was going on there.)

Martin

> On Dec 7, 2023, at 12:40 PM, Andy Goryachev  wrote:
> 
> Dear Martin:
>  
> It's hard to say.  How does it work in Swing?
>  
> There is also 
> https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role
>  
> I always felt that the focus management in JavaFX is underdeveloped: multiple 
> focused nodes, nodes getting simultaneous input, lack of coherent 
> geometry-based focus traversal policy, and a lack of public APIs for a custom 
> focus traversal policy.
>  
> Are there any ideas?
>  
> -andy
>  
>  
> From: openjfx-dev  on behalf of Martin Fox 
> 
> Date: Saturday, December 2, 2023 at 17:58
> To: John Hendrikx 
> Cc: openjfx-dev 
> Subject: Re: ToggleButton behavior
> 
> I took a look at the W3C accessibility guidelines for radio button groups 
>  since that’s the closest thing I could 
> find to a group of ToggleButtons. The W3C suggests that Tab/Shift+Tab takes 
> you in and out of the group and the arrow keys navigate within the group with 
> wrap-around. Based on that (3) is correct.
>  
> That’s where the W3C guidance ends; a single radio button doesn’t make much 
> sense so it’s not even mentioned. I would expect a single ungrouped 
> ToggleButton to navigate like a checkbox so (1) seems wrong. A group with 
> just one ToggleButton is an odd thing so (2) could go either way.
>  
> Martin
> 
> 
> On Dec 1, 2023, at 11:21 PM, John Hendrikx  wrote:
>  
> In my exploration of a potential Behavior API, I discovered this oddity in 
> how ToggleButtons work.
> 
> 1. If you have a single ToggleButton that is not part of a ToggleGroup, you 
> can't navigate away from it with the arrow keys, only by using Tab or 
> Shift-Tab.
> 
> 2. If you have that same single ToggleButton, but it does have a group (a 
> group of one) then you CAN navigate away from it with the arrow keys.
> 
> 3. When you have two ToggleButtons, both part of the same group, then you can 
> only navigate away from the group with Tab or Shift-Tab again, as the arrow 
> keys will loop back to the first/last button when the end of the group is 
> reached.
> 
> I get the impression at least one of these is incorrect.
> 
> I mean, either ToggleButtons should always loop, even if it is a group of 
> one, meaning (2) would be incorrect...
> 
> Or... ToggleButtons should never loop, in which case (1) and (3) are 
> incorrect...
> 
> Or... Single ToggleButtons (grouped or not) behave differently and don't do 
> looping, in which case (1) is incorrect
> 
> Thoughts?
> 
> --John
> 

Re: [External] : Re: ToggleButton behavior

[Andy Goryachev]

Oh yes, this is another of those boxes that belong to Pandora:

https://bugs.openjdk.org/issues/?jql=text%20~%20%22focus%20traversal%22%20AND%20project%20%3D%20JDK%20AND%20component%20%3D%20javafx%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20updated%20%20DESC

and

https://bugs.openjdk.org/browse/JDK-8292933

It’s one of those areas where we could benefit from a redesign or a proper 
FocusManager.  Right now they all sit along with the rest of ~3.5K open 
tickets, unfortunately.

I don’t know what to say.  Getting even a small improvement is extremely 
difficult – judging by one recent issue - two months of discussion result in a 
lot of good ideas and zero improvement (at least so far).  If a large Oracle 
customer escalates and requests a fix, that might help.

-andy


From: Martin Fox 
Date: Thursday, December 14, 2023 at 13:26
To: Andy Goryachev 
Cc: John Hendrikx , openjfx-dev 

Subject: [External] : Re: ToggleButton behavior
Hi Andy,

The Mozilla doc you pointed to basically re-iterates the W3C guidelines. When a 
ToggleButton is in a group it should behave like other grouped controls where 
Tab gets you into and out of the group and the arrow keys navigate within the 
group. I would still argue that an ungrouped ToggleButton should traverse like 
any other button.

I’m not familiar enough with JavaFX’s focus traversal implementation to have an 
opinion. Based on past experience I wouldn’t wade into those waters until I had 
a plan in place for how to validate the results. In my previous job we did a 
big accessibility push and ended up assigning one engineer whose primary job 
was liaising with accessibility tool vendors to make sure we got it right. She 
was worth her weight in gold.

(Whatever happened to the issue where multiple nodes in a scene can set their 
focused property? As I recall someone on the controls side needed to dig in and 
figure out what was going on there.)

Martin


On Dec 7, 2023, at 12:40 PM, Andy Goryachev  wrote:

Dear Martin:

It's hard to say.  How does it work in Swing?

There is also 
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role

I always felt that the focus management in JavaFX is underdeveloped: multiple 
focused nodes, nodes getting simultaneous input, lack of coherent 
geometry-based focus traversal policy, and a lack of public APIs for a custom 
focus traversal policy.

Are there any ideas?

-andy


From: openjfx-dev  on behalf of Martin Fox 

Date: Saturday, December 2, 2023 at 17:58
To: John Hendrikx 
Cc: openjfx-dev 
Subject: Re: ToggleButton behavior
I took a look at the W3C accessibility guidelines for radio button 
groups
 since that’s the closest thing I could find to a group of ToggleButtons. The 
W3C suggests that Tab/Shift+Tab takes you in and out of the group and the arrow 
keys navigate within the group with wrap-around. Based on that (3) is correct.

That’s where the W3C guidance ends; a single radio button doesn’t make much 
sense so it’s not even mentioned. I would expect a single ungrouped 
ToggleButton to navigate like a checkbox so (1) seems wrong. A group with just 
one ToggleButton is an odd thing so (2) could go either way.

Martin

On Dec 1, 2023, at 11:21 PM, John Hendrikx  wrote:

In my exploration of a potential Behavior API, I discovered this oddity in how 
ToggleButtons work.

1. If you have a single ToggleButton that is not part of a ToggleGroup, you 
can't navigate away from it with the arrow keys, only by using Tab or Shift-Tab.

2. If you have that same single ToggleButton, but it does have a group (a group 
of one) then you CAN navigate away from it with the arrow keys.

3. When you have two ToggleButtons, both part of the same group, then you can 
only navigate away from the group with Tab or Shift-Tab again, as the arrow 
keys will loop back to the first/last button when the end of the group is 
reached.

I get the impression at least one of these is incorrect.

I mean, either ToggleButtons should always loop, even if it is a group of one, 
meaning (2) would be incorrect...

Or... ToggleButtons should never loop, in which case (1) and (3) are 
incorrect...

Or... Single ToggleButtons (grouped or not) behave differently and don't do 
looping, in which case (1) is incorrect

Thoughts?

--John

Re: The crisp fonts saga

[John Neffenger]

On 12/14/23 4:39 AM, Mark Raynsford wrote:

The key point is "keep text aligned to the pixel grid". The thing is:
This isn't affected by hinting or the lack of it whatsoever, at least
with the way text is implemented in Prism and Freetype, as far as I can
tell.


It seems to have influenced the original choice for JavaFX. Felipe 
Heidrich addresses the font scaling issue at 30:54 in his presentation:


Hinting (30m 54s into the video)
https://www.youtube.com/watch?v=LCrCni6EVek&t=1854s

When using hinting, he says ...


You're going to compromise the intent, and again, you're going to 
compromise the linearity. So again, if you start scaling, things are 
going to start jumping.


They're going to start jumping because they've got to fix the pixel grid 
here and there, or just like, the stems or the crossbars in the glyphs 
are going to ... it will go like, point 12, point 13, 14, and things 
look to be going well, then go 14, 15, kind of gives a jump and 
everything kind of doubles.


It's because of, that's, you're on the next table in your font and 
that's what the hinting told you to do. And again, so you don't have a 
nice linear, uh, projection of your font.


So all we had here are just workarounds. [Quoting Beat Stamm] "The 
keywords here are workarounds and tolerable. Workarounds aren't real 
solutions, and they may not be equally tolerable to everybody."



Then he refers to "The Raster Tragedy at Low-Resolution," by Beat Stamm, 
which is now "The Raster Tragedy at Low-Resolution Revisited." Chapter 6 
talks about hinting:


6 Discussions
http://rastertragedy.com/RTRCh6.htm

John

Re: The crisp fonts saga

[Pedro Duque Vieira]

No you're not alone on this...
I've been complaining of poor text rendering quality on JavaFX for years
now. Though in my case, I was complaining about javafx font rendering on
Windows.
Some of the times I use to call this, that seems to improve font rendering
somewhat on some systems:

System.setProperty("prism.lcdtext", "false");


Javafx font rendering on Mac OS is better than on Windows.

When I worked for a very well known company here, we used to do all the
product screenshots on Mac because it would look noticeably better than on
Windows (I use Windows) because of the poor font rendering quality on that
OS. Given the majority of desktop users use Windows this is even more
of a problem.

My 2 cents. Cheers,
-- 
Pedro Duque Vieira - https://www.pixelduke.com


Sem
vírus.www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: The crisp fonts saga

[John Neffenger]

On 12/13/23 10:15 PM, John Neffenger wrote:
I find it helps to get the bigger picture. Below are the various camps 
as I've come to understand them over the years.


An update to my previous categorization ...

In 2018, Java Swing moved from the full-hinting group to the 
slight-hinting group, on Linux at least, when FreeType 2.8 was included 
in Linux distributions.


So a better grouping of rendering policies is:

Subpixel rendering with normal hinting
- Microsoft Windows
- Java Swing on Linux (before FreeType 2.8)

Subpixel rendering with "slight" hinting
- Ubuntu
- Java Swing on Linux (after FreeType 2.8)

Subpixel rendering with hinting disabled
- JavaFX on Linux

Gray-level rendering with hinting disabled
- Apple macOS

I always wondered why text rendering in Swing apps on Linux got so much 
better around 2018. Turns out FreeType made the switch under the covers 
with the following change [1]:


- FT_LOAD_TARGET_LCD is now a variant of FT_LOAD_TARGET_LIGHT;
  this should provide better rendering results.

Better indeed! A five-year mystery (to me, at least) solved. :-)

John

[1]: https://sourceforge.net/projects/freetype/files/freetype2/2.8/