Re: RFR: 8267551: Support loading images from inline data-URIs [v11]

[Michael Strauß]

> This PR adds support for loading images from [inline data 
> URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely 
> supported by web browsers. This enables developers to package small images in 
> CSS files, rather than separately deploying the images alongside the CSS file.

Michael Strauß 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 13 additional commits 
since the last revision:

 - Merge branch 'openjdk:master' into feature/image-datauri
 - Rename DataURI.isValidURI
 - Reverted a change
 - Allow leading and trailing whitespace in data URI
 - Removed test
 - Changed data URI detection
 - Merge branch 'master' into feature/image-datauri
 - Moved test
 - Added javadoc
 - Added javadoc
 - ... and 3 more: https://git.openjdk.java.net/jfx/compare/fc92ab9f...f6878f51

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/508/files
  - new: https://git.openjdk.java.net/jfx/pull/508/files/edb6f658..f6878f51

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx=508=10
 - incr: https://webrevs.openjdk.java.net/?repo=jfx=508=09-10

  Stats: 559 lines in 12 files changed: 386 ins; 145 del; 28 mod
  Patch: https://git.openjdk.java.net/jfx/pull/508.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508

PR: https://git.openjdk.java.net/jfx/pull/508

Integrated: 8252783: Remove the css Selector and ShapeConverter constructors

[Ajit Ghaisas]

On Fri, 21 May 2021 11:48:21 GMT, Ajit Ghaisas  wrote:

> The javafx.css.Selector and javafx.css.converter.ShapeConverter constructors 
> were deprecated for removal in openjfx16.
> This PR removes these constructors (targeted for openjfx17).

This pull request has now been integrated.

Changeset: a645b5a4
Author:Ajit Ghaisas 
URL:   
https://git.openjdk.java.net/jfx/commit/a645b5a4925af00835510ce8fd88068f0f7a2e45
Stats: 8 lines in 2 files changed: 0 ins; 5 del; 3 mod

8252783: Remove the css Selector and ShapeConverter constructors

Reviewed-by: kcr, pbansal

-

PR: https://git.openjdk.java.net/jfx/pull/512

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4]

[Martin Fox]

On Tue, 25 May 2021 10:40:50 GMT, Tom Schindl  wrote:

>> Is there some reason you would prefer a Swing-style implementation over the 
>> approach I submitted in this PR? The Swing code breaks down if an 
>> accelerator calls for the Option modifier alone or in addition to Command. 
>> I'm still investigating work-arounds.
>> 
>> (Long story short, Command alters the character we receive in a good way, 
>> providing a low-ASCII character even on non-ASCII layouts like Cyrillic. 
>> Option alters the character in a bad way, often producing an arbitrary 
>> symbol. Prior to macOS 10.15 we can't toss one modifier without tossing the 
>> other short of using UCKeyTranslate.)
>
> @beldenfox I did not say that the swing version is the way to go and in the 
> end its @kevinrushforth call what route should be taken - I just wanted to 
> show what my initial change would have been without saying it is better than 
> what you are proposing which sounds like is more complete than what swing 
> provides today.

@tomsontom I've added the Swing-style code as WIP PR #519. There are comments 
in the PR that probably should be in the code but I wanted to reduce the code 
diffs.

PR #519 (and Swing) tend to get codes for punctuation keys wrong on non-US 
layouts. That's not a big issue for accelerator processing since accelerators 
involving punctuation should use KeyCharacterCombinations which work even if 
the underlying key codes are wrong.  (I can't seem to find documentation that 
tells developers how to choose between KeyCodeCombinations and 
KeyCharacterCombinations. Am I missing something?)

There are isolated instances where PR #519 assigns a letter code to a 
punctuation key. For example, on the French keyboard it assigns KeyCode.M to 
the comma/question mark key which is where the M key is on the US layout. This 
means an app that uses both M and one of those punctuation characters as 
accelerators might see both fire. This might be a non-issue, the same problem 
afflicts the current code and I didn't run across any bugs on that.

-

PR: https://git.openjdk.java.net/jfx/pull/425

Unknown command v - for a list of valid commands use /help.

[John Neffenger]

$ grep -A2 'reg query' build/vcvarsall.log
C:\cygwin64\home\john\src\jfx>for /F "tokens=1,2*" %i in
('reg query "HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v10.0"


I did it again -- started a line with a Windows command option inside a 
Shell Session code block, resulting in a truncated message on the 
mailing list and the feedback:


  Unknown command v - for a list of valid commands use /help.

For my full comment, please see:

https://github.com/openjdk/jfx/pull/488#issuecomment-848264495

Sorry about that.

John

Re: RFR: 8266396: Save VSCMD_DEBUG output in Windows build [v3]

[John Neffenger]

On Thu, 13 May 2021 19:11:26 GMT, John Neffenger  wrote:

>> John Neffenger has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Skip sending telemetry to fix "file in use" error
>
> I wrote a Bash shell script, included below, that can help in reviewing this 
> pull request. It isolates the call to `vcvarsall.bat`, making it easier to 
> experiment with different choices, such as:
> 
> - leaving `VSCMD_SKIP_SENDTELEMETRY` undefined,
> - adding the `/q` option to `cmd`,
> - removing `2>&1` to use the default standard error, or
> - discarding standard output with `> /dev/null`.
> 
> 
> #!/bin/bash
> # Tests the Visual Studio 'vcvarsall.bat' batch file
> trap exit INT TERM
> set -o errexit
> 
> # Path to 'vcvarsall.bat' batch file
> vsroot="C:\\Program Files (x86)\\Microsoft Visual Studio"
> vcfile="2019\\Community\\VC\\Auxiliary\\Build\\vcvarsall.bat"
> vcpath="$vsroot\$vcfile"
> 
> # Windows command interpreter and options
> #   /C  Carries out the command specified by string and then terminates
> #   /Q  Turns echo off
> command="cmd /c"
> 
> # Skips calling PowerShell script to send telemetry
> export VSCMD_SKIP_SENDTELEMETRY="1"
> printf "VSCMD_SKIP_SENDTELEMETRY="%s"\n" "$VSCMD_SKIP_SENDTELEMETRY"
> 
> # VSCMD_DEBUG undefined
> unset VSCMD_DEBUG
> printf "Testing VSCMD_DEBUG="%s"\n" "$VSCMD_DEBUG"
> $command "$vcpath" x86 > 0-debug.log 2>&1
> $command "$vcpath" x64 >> 0-debug.log 2>&1
> 
> # VSCMD_DEBUG = 1 (basic), 2 (detailed), and 3 (trace)
> for n in 1 2 3; do
> export VSCMD_DEBUG="$n"
> printf "Testing VSCMD_DEBUG="%s"\n" "$VSCMD_DEBUG"
> $command "$vcpath" x86 > $n-debug.log 2>&1
> $command "$vcpath" x64 >> $n-debug.log 2>&1
> done
> 
> 
> I run the script under Cygwin on Windows and evaluate its output as follows:
> 
> 
> $ ./vcvarstest.sh
> VSCMD_SKIP_SENDTELEMETRY="1"
> Testing VSCMD_DEBUG=""
> Testing VSCMD_DEBUG="1"
> Testing VSCMD_DEBUG="2"
> Testing VSCMD_DEBUG="3"
> $ wc -l *.log
> 10 0-debug.log
> 92 1-debug.log
>508 2-debug.log
>   5690 3-debug.log
>   6300 total

> @jgneff, do you have an idea of what kind of errors would be better detected 
> with these changes?

Thanks for trying it, Joeri. The intent is to make all such errors better 
detected, but that can happen only when you run the build with `VSCMD_DEBUG=3` 
and when you're able to find the errors in the log file.

Without `VSCMD_DEBUG=3`, the batch files discard the output and errors of each 
`reg query` command, as shown below in the file `winsdk.bat`:


:GetWin10SdkDir

if "%VSCMD_DEBUG%" GEQ "3" goto :GetWin10SdkDirVerbose

call :GetWin10SdkDirHelper HKLM\SOFTWARE\Wow6432Node > nul 2>&1


In addition, it helps to have an idea what to look for in the log file because 
not all errors are prefixed with something helpful like `ERROR`. In the test 
that you ran, the following steps could lead you to the source of the problem:


$ export VSCMD_DEBUG=3
$ gradle sdk
   ︙
> FAIL: WINSDK_DIR not defined
   ︙
$ grep -A2 'reg query' build/vcvarsall.log
C:\cygwin64\home\john\src\jfx>for /F "tokens=1,2*" %i in
('reg query "HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v10.0"

-

PR: https://git.openjdk.java.net/jfx/pull/488

Re: Make themes a first-class concept in JavaFX

[Michael Strauß]

Maybe others will chime in regarding the thin vs. rich API discussion.

Regarding the extensibility of themes:

If Modena and Caspian were public API, you could extend those themes
simply by subclassing:

public class CustomTheme extends Modena {
private final ObservableList allStylesheets =
FXCollections.observableArrayList();

private final ObservableList customStylesheets =
FXCollections.observableArrayList();

public CustomTheme(Map properties) {
super(properties);

// Add custom stylesheets here
customStylesheets.add("com/example/custom.css");

// Combine with Modena stylesheets
allStylesheets = new ListBinding<>() {
   {  bind(super.getStylesheets(), customStylesheets); }

   @Override
   protected ObservableList computeValue() {
   return FXCollections.concat(
   super.getStylesheets(), customStylesheets);
   }
};
}

@Override
public ObservableList getStylesheets() {
return allStylesheets;
}
}



Am Di., 25. Mai 2021 um 13:06 Uhr schrieb Pedro Duque Vieira
:
>
> Again thanks for bringing this up into discussion and for taking the time to 
> file a PR, etc. I like the idea of having better support for themes.
>
> Regarding your first point:
> 1 - To keep it simple we can discard the idea of having an API to be able to 
> check what are the OS settings for dark/light, accent color, etc, for now. I 
> think that this can be a separate discussion.
> We could simply start by having an API that a theme has to implement 
> (probably an interface that the theme has to implement like what I think 
> happens with your proposed API). That API has properties: dark/light style, 
> accent color, etc. Each theme can decide to respond or not to changes in 
> those properties hence decide whether or not to support these features.
>
> Regarding the second point:
> 2 - Not sure I explained myself well.
> What I meant was that right now, and it happens to all themes I know of, 
> theme creators decide to extend the Modena theme. What I mean by "extend" is 
> that they add stylesheets to the Scene/Parent (without being user agent 
> stylesheets). This means they simply build on top of the rules in Modena 
> which is much easier/better but also means that the rules they define in 
> their stylesheets will trump any rules defined by the theme users in their 
> FXMLs, stylesheets (depending on specificity of their rules in their 
> stylesheets), code...
> I think this can be confusing and not ideal for users of these themes, and I 
> find most of the time theme users don't even know about JavaFX user agent 
> stylesheets feature vs Scene/Parent stylesheets and what that implies.
> What I would propose is to have an API, perhaps in this theme interface, that 
> toggles whether the theme, theme creators are creating will be a user agent 
> stylesheet or a regular stylesheet. The advantage would be that if it is a 
> user agent stylesheet developers won't need to copy all Modena definitions 
> into their theme stylesheets, they can simply toggle this boolean to say what 
> kind of stylesheet they want their theme to be.
>
> Thanks,

Re: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14]

[Ambarish Rapte]

On Mon, 24 May 2021 05:02:45 GMT, Nir Lisker  wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 55:
>> 
>>> 53:  * {@code falloff >= 0}; values outside either of these ranges can 
>>> produce unexpected results.
>>> 54:  * 
>>> 55:  * 
>> 
>> Should we have cone depicted in the diagram ?
>
> Not sure how to do that in a clear way. If you want to create an image I will 
> use it.

I shall try to create a diagram.

-

PR: https://git.openjdk.java.net/jfx/pull/334

Re: RFR: 8234920: Add SpotLight to the selection of 3D light types [v15]

[Ambarish Rapte]

On Mon, 24 May 2021 05:08:13 GMT, Nir Lisker  wrote:

>> Added a SpotLight only to the D3D pipeline currently.
>> 
>> ### API discussion points
>> 
>> - [X]  Added `SpotLight` as a subclass of `LightBase`. However, it could 
>> also be a subclass of `PointLight` as it's a point light with direction and 
>> extra factors. I saw that `scenario.effect.light.SpotLight` extends its 
>> respective `PointLight`, but it's not a perfect analogy. In the end, I think 
>> it's a questions of whether `PointLight` will be expanded in a way which 
>> doesn't not suit `SpotLight`, and I tend to think that the answer is no.
>> 
>> - [X] The inner and outer angles are the "diameter angles" as shown 
>> [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types).
>>   I, personally, find it more intuitive that these are the "radius angles", 
>> so half these angles, as used in the spotlight factor formula. Do you think 
>> I can change this or do you prefer the current definition of the angles?
>> 
>> - [ ] The current implementation uses an ad-hoc direction property (using a 
>> `Point3D`). It crossed my mind that we could use the rotation transforms of 
>> the node to control the direction instead, just like we use the 
>> translation/layout of the node to get the position (there is an internal 
>> Affine3D transform for lights, not sure why `AmbientLight` needs it). 
>> Wouldn't that make more sense? When I rotate the light I would expect to see 
>> a change in direction.
>> 
>> ### Implementation discussion points
>> 
>> - [ ] I've gotten advice from a graphics engineer to treat point lights as 
>> spot lights with a 360 degrees coverage, which simplifies a few places. We 
>> can still try to optimize for a point light by looking at the light 
>> parameters: `falloff = 0` and `outerAngle = 180`. These possible 
>> optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the 
>> pixel/fragment shaders in the form of 3 different ways to compute the 
>> spotlight factor (the `computeLightN` methods). We need to check which of 
>> these give the best results.
>> 
>> ## Performance
>> 
>> Testing 3 point lights and comparing this branch with `master` using a 1000 
>> division sphere, 200 meshes, and 5000 meshes.
>> Using an AMD RX 470 4GB GPU.
>> 
>> In this branch, there is a possible CPU optimization for checking the light 
>> type and using precalculated values (in `D3DMeshView.cc` for d3d and 
>> `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing 
>> the spotlight factor contributions (`computeSpotlightFactor`, 
>> `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out 
>> different branching and shortcuts.
>> 
>> ### Results
>> The CPU "optimizations" made no difference, which is understandable 
>> considering it will not be the bottleneck. We can remove these if we want to 
>> simplify, though maybe if we allow a large number of lights it could make a 
>> difference (I doubt it). I don't have a strong preference either way.
>> 
>> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu).
>> 
>> **Win 10**
>> Compared with the `master` branch, this patch shows 5-10 fps drop in the 
>> mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several 
>> occasions and got different results in terms of absolute numbers, but the 
>> relative performance difference remained more or less the same. Out of the 3 
>> `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no 
>> "optimizations", gives slightly better performance.
>> 
>> **Ubuntu 18**
>> The mesh 200 test always gave 60 fps because it is locked to this fps, so we 
>> can't measure the real GPU performance change.
>> The mesh 5000 test shows 2-6 fps drop from master, with 
>> `computeSpotlightFactor` > `computeSpotlightFactor2`  > 
>> `computeSpotlightFactor3` at in terms of performance (~2 fps difference 
>> each).
>> 
>> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. 
>> `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave 
>> the best performances.
>
> Nir Lisker has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Update documentation

Suggested few doc changes. I have little concern about how the angle of 
cone/illumination of point is described. Have put a comment for innerAngle 
description and similar would apply to outer angle.

modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGPointLight.java 
line 48:

> 46: /**
> 47:  * The direction of a {@code SpotLight} that simulates a {@code 
> PointLight}.
> 48:  * Since the light radiates equaly in all directions, this value is 
> meaningless.

minor: equaly -> equally

modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java 
line 167:

> 165: //float attenuationFactor = 

Re: RFR: 8239138: StyleManager should use a BufferedInputStream

[Kevin Rushforth]

On Tue, 25 May 2021 09:04:07 GMT, Ambarish Rapte  wrote:

> `StyleManager.calculateCheckSum()` uses a raw InputStream as the input to a 
> `DigestInputStream` and reads one byte at a time. This is slower in 
> performance and should be changed, either to use `BufferedInputStream` or 
> read byte buffer of 4096 from the stream or use both.
> 
> I have tried three approaches and tested with modena.css which is ~134 KB in 
> size.
> Following are the approaches and time in milliseconds taken by the method 
> StyleManager.calculateCheckSum(), collected from 25 readings,
> 
> 1. Use BufferedInputStream and read one byte at a time 
> [commit#1](https://github.com/openjdk/jfx/commit/6cd7d44d0ce1084c6cdb06a698c7aca127a615ef)
>  : 
> - Maximum: 53 ms,  Minimum: 27 ms, Average: 39 ms
> 2. Use BufferedInputStream and read buffer of 4096 at a time 
> [commit#1+2](https://github.com/openjdk/jfx/pull/518/files/6e0c621ea62691d5402b2bca5951d1012a5b1b91)
> - Maximum: 17 ms,  Minimum: 14 ms, Average: 15.58 ms
> 3. Use raw InputStream(current implementation) and read buffer of 4096 at a 
> time 
> [commit#1+2+3](https://github.com/openjdk/jfx/pull/518/files/215e1a183cfb902247f0d48685f7a901cb5fb003),
>  which also similar to `NativeLibLoader.calculateCheckSum()` and looks faster 
> than previous two.
> - Maximum: 16 ms,  Minimum: 13 ms, Average: 14.25 ms
> 
> 
> The time taken by `StyleManager.calculateCheckSum()` with current 
> implementation is,
> - Maximum: 61 ms,  Minimum: 38 ms, Average: 50.58 ms
> 
> 
> Both approaches 2 & 3 show good improvement. I would prefer approach#3 as it 
> is similar to `NativeLibLoader.calculateCheckSum()`.
> However we can choose approach#2 also.
> If we choose approach#3 then bug summary should be changed accordingly.

I also prefer approach 3, since the body of the try/finally loop is then 
identical to that of `NativeLibLoader::calculateCheckSum`.

Can you add a unit test to validate the checksum method? It should be 
sufficient to do this by taking a file that is > 4096 bytes, but not a multiple 
of 4096, manually running `md5sum` on it to get its checksum that you can then 
use to compare with the computed one.

-

PR: https://git.openjdk.java.net/jfx/pull/518

Re: RFR: 8266396: Save VSCMD_DEBUG output in Windows build [v3]

[Joeri Sykora]

On Thu, 13 May 2021 19:11:26 GMT, John Neffenger  wrote:

>> John Neffenger has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Skip sending telemetry to fix "file in use" error
>
> I wrote a Bash shell script, included below, that can help in reviewing this 
> pull request. It isolates the call to `vcvarsall.bat`, making it easier to 
> experiment with different choices, such as:
> 
> - leaving `VSCMD_SKIP_SENDTELEMETRY` undefined,
> - adding the `/q` option to `cmd`,
> - removing `2>&1` to use the default standard error, or
> - discarding standard output with `> /dev/null`.
> 
> 
> #!/bin/bash
> # Tests the Visual Studio 'vcvarsall.bat' batch file
> trap exit INT TERM
> set -o errexit
> 
> # Path to 'vcvarsall.bat' batch file
> vsroot="C:\\Program Files (x86)\\Microsoft Visual Studio"
> vcfile="2019\\Community\\VC\\Auxiliary\\Build\\vcvarsall.bat"
> vcpath="$vsroot\$vcfile"
> 
> # Windows command interpreter and options
> #   /C  Carries out the command specified by string and then terminates
> #   /Q  Turns echo off
> command="cmd /c"
> 
> # Skips calling PowerShell script to send telemetry
> export VSCMD_SKIP_SENDTELEMETRY="1"
> printf "VSCMD_SKIP_SENDTELEMETRY="%s"\n" "$VSCMD_SKIP_SENDTELEMETRY"
> 
> # VSCMD_DEBUG undefined
> unset VSCMD_DEBUG
> printf "Testing VSCMD_DEBUG="%s"\n" "$VSCMD_DEBUG"
> $command "$vcpath" x86 > 0-debug.log 2>&1
> $command "$vcpath" x64 >> 0-debug.log 2>&1
> 
> # VSCMD_DEBUG = 1 (basic), 2 (detailed), and 3 (trace)
> for n in 1 2 3; do
> export VSCMD_DEBUG="$n"
> printf "Testing VSCMD_DEBUG="%s"\n" "$VSCMD_DEBUG"
> $command "$vcpath" x86 > $n-debug.log 2>&1
> $command "$vcpath" x64 >> $n-debug.log 2>&1
> done
> 
> 
> I run the script under Cygwin on Windows and evaluate its output as follows:
> 
> 
> $ ./vcvarstest.sh
> VSCMD_SKIP_SENDTELEMETRY="1"
> Testing VSCMD_DEBUG=""
> Testing VSCMD_DEBUG="1"
> Testing VSCMD_DEBUG="2"
> Testing VSCMD_DEBUG="3"
> $ wc -l *.log
> 10 0-debug.log
> 92 1-debug.log
>508 2-debug.log
>   5690 3-debug.log
>   6300 total

@jgneff, do you have an idea of what kind of errors would be better detected 
with these changes? For instance, I've changed the `PATH` environment variable 
so that it no longer includes `/cygdrive/c/Windows/System32`. When running 
`./gradlew help` it fails as expected with the known message:

> FAIL: WINSDK_DIR not defined

However, while inspecting the `build/vcvarsall.log` file to look for clues, it 
didn't reveal anything interesting to point me to the possible cause of the 
gradle failure. From the looks of it, it even seems to have been successfully 
executed.

-

PR: https://git.openjdk.java.net/jfx/pull/488

RFR: 8239138: StyleManager should use a BufferedInputStream

[Ambarish Rapte]

`StyleManager.calculateCheckSum()` uses a raw InputStream as the input to a 
`DigestInputStream` and reads one byte at a time. This is slower in performance 
and should be changed, either to use `BufferedInputStream` or read byte buffer 
of 4096 from the stream or use both.

I have tried three approaches and tested with modena.css which is ~134 KB in 
size.
Following are the approaches and time in milliseconds taken by the method 
StyleManager.calculateCheckSum(), collected from 25 readings,

1. Use BufferedInputStream and read one byte at a time 
[commit#1](https://github.com/openjdk/jfx/commit/6cd7d44d0ce1084c6cdb06a698c7aca127a615ef)
 : 
- Maximum: 53 ms,  Minimum: 27 ms, Average: 39 ms
2. Use BufferedInputStream and read buffer of 4096 at a time 
[commit#1+2](https://github.com/openjdk/jfx/pull/518/files/6e0c621ea62691d5402b2bca5951d1012a5b1b91)
- Maximum: 17 ms,  Minimum: 14 ms, Average: 15.58 ms
3. Use raw InputStream(current implementation) and read buffer of 4096 at a 
time 
[commit#1+2+3](https://github.com/openjdk/jfx/pull/518/files/215e1a183cfb902247f0d48685f7a901cb5fb003),
 which also similar to `NativeLibLoader.calculateCheckSum()` and looks faster 
than previous two.
- Maximum: 16 ms,  Minimum: 13 ms, Average: 14.25 ms


The time taken by `StyleManager.calculateCheckSum()` with current 
implementation is,
- Maximum: 61 ms,  Minimum: 38 ms, Average: 50.58 ms


Both approaches 2 & 3 show good improvement. I would prefer approach#3 as it is 
similar to `NativeLibLoader.calculateCheckSum()`.
However we can choose approach#2 also.
If we choose approach#3 then bug summary should be changed accordingly.

-

Commit messages:
 - only buffer[4096], similar to NativeLibLoader.calculateCheckSum()
 - BufferedInputStream + buffer[4096]
 - use BufferedInputStream

Changes: https://git.openjdk.java.net/jfx/pull/518/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx=518=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8239138
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/518.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/518/head:pull/518

PR: https://git.openjdk.java.net/jfx/pull/518

Re: Make themes a first-class concept in JavaFX

[Pedro Duque Vieira]

Again thanks for bringing this up into discussion and for taking the time
to file a PR, etc. I like the idea of having better support for themes.

Regarding your first point:
1 - To keep it simple we can discard the idea of having an API to be able
to check what are the OS settings for dark/light, accent color, etc, for
now. I think that this can be a separate discussion.
We could simply start by having an API that a theme has to implement
(probably an interface that the theme has to implement like what I think
happens with your proposed API). That API has properties: dark/light style,
accent color, etc. Each theme can decide to respond or not to changes in
those properties hence decide whether or not to support these features.

Regarding the second point:
2 - Not sure I explained myself well.
What I meant was that right now, and it happens to all themes I know of,
theme creators decide to extend the Modena theme. What I mean by "extend"
is that they add stylesheets to the Scene/Parent (without being user agent
stylesheets). This means they simply build on top of the rules in Modena
which is much easier/better but also means that the rules they define in
their stylesheets will trump any rules defined by the theme users in their
FXMLs, stylesheets (depending on specificity of their rules in their
stylesheets), code...
I think this can be confusing and not ideal for users of these themes, and
I find most of the time theme users don't even know about JavaFX user agent
stylesheets feature vs Scene/Parent stylesheets and what that implies.
What I would propose is to have an API, perhaps in this theme interface,
that toggles whether the theme, theme creators are creating will be a user
agent stylesheet or a regular stylesheet. The advantage would be that if it
is a user agent stylesheet developers won't need to copy all Modena
definitions into their theme stylesheets, they can simply toggle this
boolean to say what kind of stylesheet they want their theme to be.

Thanks,



On Mon, May 24, 2021 at 11:48 PM Michael Strauß 
wrote:

> I can understand that parsing string values feels like a very
> lackluster API. But let me offer a counterpoint:
>
> If we provided a set of APIs that exposed particular OS concepts
> (light/dark mode, accent coloring, etc.), we would commit ourselves to
> supporting these APIs for new versions of all kinds of operating
> systems. We'd also need additional APIs to expose whether or not the
> particular concept is even available on the current OS. I think
> developers would then also expect us to keep track of the changing
> trends of OS design and keep offering up-to-date APIs for new features
> and design trends. That's a significant cost, considering that JavaFX
> currently doesn't even offer a theme that would need all these APIs
> (except for high contrast).
>
> On the other hand, assuming the proposed minimal `Theme` API, it would
> be pretty straightforward for a third-party library to implement
> `Theme` adapters that offer all of the first-class APIs that you
> discussed.
>
> As to you other point: in order to be able to extend the build-in
> themes, their theme implementations would need to be public API. In
> general I think that's okay, provided that the inner workings of the
> default themes remain a "black box".
>
>
>
> Am Mo., 24. Mai 2021 um 17:48 Uhr schrieb Pedro Duque Vieira
> :
> >
> > Hi,
> >
> > I've been developing JMetro:
> https://pixelduke.com/java-javafx-theme-jmetro/
> > , it's a javafx I've been developing since 2013 when I have some free
> spare
> > time.
> >
> > I thought I'd chime in since this has been an interest of mine for quite
> > some time.
> >
> > A few issues I experience with the current JavaFX API:
> >
> > 1 - Like Michael said here, the current way all themes are usually
> > developed is to extend the default JavaFX theme (currently modena). This
> > has a few problems:
> > 1.1 - If you want it to be a user agent stylesheet you have to copy
> > everything from the default theme into your theme
> > 1.2 - If you're NOT going to go for it being an user agent stylesheet,
> you
> > simply add your theme "on top" of the default user agent stylesheet (e.g.
> > Modena) but this has a problem because now the rules of your theme will
> > have precedence over rules set through code (e.g. style rules in FXML,
> > style rules in code).. which can be unexpected from a user using the
> theme.
> >
> > 2 - There's no built-in support for new theme features existing in most
> > Operating Systems nowadays like: dark/light style, chosen accent color...
> >
> > ---
> >
> > I think adding an API to solve this is a good idea.
> > As a first comment and focusing only on the stuff I would change, I don't
> > particularly like the "void platformThemeChanged(Map
> > properties);"
> > Namely the fact that we're using strings to identify properties like
> > whether we use dark or light style, etc. I would prefer as a developer to
> > not have to match strings, etc 

Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4]

[Tom Schindl]

On Mon, 24 May 2021 15:25:22 GMT, Martin Fox 
 wrote:

>> Martin Fox has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Fixed whitespace error.
>
> Is there some reason you would prefer a Swing-style implementation over the 
> approach I submitted in this PR? The Swing code breaks down if an accelerator 
> calls for the Option modifier alone or in addition to Command. I'm still 
> investigating work-arounds.
> 
> (Long story short, Command alters the character we receive in a good way, 
> providing a low-ASCII character even on non-ASCII layouts like Cyrillic. 
> Option alters the character in a bad way, often producing an arbitrary 
> symbol. Prior to macOS 10.15 we can't toss one modifier without tossing the 
> other short of using UCKeyTranslate.)

@beldenfox I did not say that the swing version is the way to go and in the end 
its @kevinrushforth call what route should be taken - I just wanted to show 
what my initial change would have been without saying it is better than what 
you are proposing which sounds like is more complete than what swing provides 
today.

-

PR: https://git.openjdk.java.net/jfx/pull/425

Re: RFR: 8234920: Add SpotLight to the selection of 3D light types [v16]

[Nir Lisker]

> Added a SpotLight only to the D3D pipeline currently.
> 
> ### API discussion points
> 
> - [X]  Added `SpotLight` as a subclass of `LightBase`. However, it could also 
> be a subclass of `PointLight` as it's a point light with direction and extra 
> factors. I saw that `scenario.effect.light.SpotLight` extends its respective 
> `PointLight`, but it's not a perfect analogy. In the end, I think it's a 
> questions of whether `PointLight` will be expanded in a way which doesn't not 
> suit `SpotLight`, and I tend to think that the answer is no.
> 
> - [X] The inner and outer angles are the "diameter angles" as shown 
> [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types).
>   I, personally, find it more intuitive that these are the "radius angles", 
> so half these angles, as used in the spotlight factor formula. Do you think I 
> can change this or do you prefer the current definition of the angles?
> 
> - [ ] The current implementation uses an ad-hoc direction property (using a 
> `Point3D`). It crossed my mind that we could use the rotation transforms of 
> the node to control the direction instead, just like we use the 
> translation/layout of the node to get the position (there is an internal 
> Affine3D transform for lights, not sure why `AmbientLight` needs it). 
> Wouldn't that make more sense? When I rotate the light I would expect to see 
> a change in direction.
> 
> ### Implementation discussion points
> 
> - [ ] I've gotten advice from a graphics engineer to treat point lights as 
> spot lights with a 360 degrees coverage, which simplifies a few places. We 
> can still try to optimize for a point light by looking at the light 
> parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization 
> exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the 
> pixel/fragment shaders in the form of 3 different ways to compute the 
> spotlight factor (the `computeLightN` methods). We need to check which of 
> these give the best results.
> 
> ## Performance
> 
> Testing 3 point lights and comparing this branch with `master` using a 1000 
> division sphere, 200 meshes, and 5000 meshes.
> Using an AMD RX 470 4GB GPU.
> 
> In this branch, there is a possible CPU optimization for checking the light 
> type and using precalculated values (in `D3DMeshView.cc` for d3d and 
> `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing 
> the spotlight factor contributions (`computeSpotlightFactor`, 
> `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different 
> branching and shortcuts.
> 
> ### Results
> The CPU "optimizations" made no difference, which is understandable 
> considering it will not be the bottleneck. We can remove these if we want to 
> simplify, though maybe if we allow a large number of lights it could make a 
> difference (I doubt it). I don't have a strong preference either way.
> 
> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu).
> 
> **Win 10**
> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 
> 200 test and ~5 in the mesh 5000 test. I repeated the tests on several 
> occasions and got different results in terms of absolute numbers, but the 
> relative performance difference remained more or less the same. Out of the 3 
> `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no 
> "optimizations", gives slightly better performance.
> 
> **Ubuntu 18**
> The mesh 200 test always gave 60 fps because it is locked to this fps, so we 
> can't measure the real GPU performance change.
> The mesh 5000 test shows 2-6 fps drop from master, with 
> `computeSpotlightFactor` > `computeSpotlightFactor2`  > 
> `computeSpotlightFactor3` at in terms of performance (~2 fps difference each).
> 
> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. 
> `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave 
> the best performances.

Nir Lisker has updated the pull request with a new target base due to a merge 
or a rebase. The pull request now contains 35 commits:

 - Merge remote-tracking branch 'origin/master' into 
8234920_Add_SpotLight_to_the_selection_of_3D_light_types
 - Merge branch 'master' into 
8234920_Add_SpotLight_to_the_selection_of_3D_light_types
 - Update documentation
 - Combined rotation and direction
 - Corrected light direction in the es2 pipeline
 - Restored PointLight test
 - Removed whitespace
 - Updated the system test
 - Merge remote-tracking branch 
'nlisker/8234920_Add_SpotLight_to_the_selection_of_3D_light_types' into 
8234920_Add_SpotLight_to_the_selection_of_3D_light_types
 - Merge remote-tracking branch
 - ... and 25 more: https://git.openjdk.java.net/jfx/compare/329013b3...1cff7527

-

Changes: https://git.openjdk.java.net/jfx/pull/334/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx=334=15
  

Re: Minimum JDK policy for OpenJFX

[Ty Young]

GTK4 was just released not that long ago. I don't know how much(if any 
at all) code is shared between versions, but having a tool like jextract 
might be useful for adding support for that. Just a guess.



Also, the bindings are different in that, for everything not a primitive 
in java(except boolean and char), you need to allocate memory and pass 
the address of the memory to the function(e.g. structs, unions, arrays). 
You also need to, depending on which ResourceScope is used, explicitly 
free your memory.



And, again, everything is in Java.


Maybe the ability to allocate off-heap arrays is useful somehow? Maybe 
to somehow reduce GC pressure when resizing the application or something?



On 5/25/21 3:59 AM, Nir Lisker wrote:
I looked at jextract a while back. I got the impression that it's more 
useful when you need to generate new bindings, at the very least 
because there are fewer ways to make mistakes. Most of the work on 
JavaFX has already been done in this area and the mistakes have been 
found and fixed by now, so is there any substantial value in redoing 
it with jextract?


On Thu, May 20, 2021 at 12:25 AM Ty Young > wrote:


If you want to learn more about Panama you can read the JEP page:


https://openjdk.java.net/jeps/412 


You can also join the panama-dev list and ask questions:


https://mail.openjdk.java.net/mailman/listinfo/panama-dev



Biggest things for JavaFX that I can think of is jextract, a tool for
generating Java headers from a C header, and having all binding code
written in Java. It may be easier to upgrade to newer GTK versions
using
Panama as there is no C shim required and the bindings are, again,
generated for you. jextract does have issues, one of which is that
any
binding generated using it are platform-specific even if the library
itself is cross-platform. You can make bindings by hand that are
cross-platform if you want, though.


Speaking of GTK, when is JavaFX going to support GTK4?




On 5/18/21 4:42 PM, Nir Lisker wrote:
>> there are some advantages in being able to run with the latest
JDK LTS
>>
> One *potential* issue with this approach is that LTS is not
defined in
> OpenJDK as far as I know. The LTS versions are a business
decision of each
> distributor. For now, they have all aligned on 8, 11, 17, but
nothing
> guarantees that this will stay so. What if different vendors LTS
different
> versions? Suppose that Valhalla and Loom add very attractive
features in
> JDK 19 (big performance enhancements, leads to big money savings on
> hardware, leads to economic incentives to use these, leads to
requests to
> support these), now vendors can declare JDK 19 as LTS, and what
will JavaFX
> do?
> In OpenJDK all versions are treated equally as it is a spec and
not a
> business model. Should JavaFX be coupled to business models?
Maybe Gluon
> has some insights since they give JavaFX LTS support.
>
> A second point, as Michael Strauß mentioned, is that maybe we
should see
> what features are going to be delivered in the next versions and
judge if
> there's something attractive enough for library developers to
base our
> decision on. Sealed classes from Amber are certainly one of
them. Panama
> might provide handy features for JavaFX's interfacing with
native code,
> like Foreign Memory Access, though I didn't look into it in detail.
> Valhalla is certainly too far away to consider, and Loom is rather
> irrelevant for JavaFX and GUIs in general.
> If anyone has insights into relevant upcoming features I'll be
happy to
> learn.
>
> - Nir
>
> On Tue, May 18, 2021 at 6:17 PM Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>>
> wrote:
>
>> A very timely question. I was already planning to raise this as a
>> discussion after we update our boot JDK to JDK 16 (blocked by the
>> in-progress gradle 7 update), which I hope to do later this week.
>>
>> I think that this is the right time to consider bumping the minimum
>> required version to run JavaFX 17 to JDK 16, which would allow
us to
>> start using APIs and language features from JDK 12 through JDK 16
>> inclusive.
>>
>> In general, we only guarantee that JavaFX N runs on JDK N-1 or
later. In
>> practice, though, we don't bump it for each release, as there
are some
>> advantages in being able to run with the latest JDK LTS. Since
JavaFX 17
>> will release at roughly the same time as JDK 17 LTS, I can't
think of a
>> good reason to not update our minimum.
>>
>> Comments?
>>
>> -- Kevin
>>
>>
>> On 5/18/2021 7:59 AM, Michael Strauß wrote:
  

Re: RFR: 8234920: Add SpotLight to the selection of 3D light types [v15]

[Ambarish Rapte]

On Mon, 24 May 2021 05:08:13 GMT, Nir Lisker  wrote:

>> Added a SpotLight only to the D3D pipeline currently.
>> 
>> ### API discussion points
>> 
>> - [X]  Added `SpotLight` as a subclass of `LightBase`. However, it could 
>> also be a subclass of `PointLight` as it's a point light with direction and 
>> extra factors. I saw that `scenario.effect.light.SpotLight` extends its 
>> respective `PointLight`, but it's not a perfect analogy. In the end, I think 
>> it's a questions of whether `PointLight` will be expanded in a way which 
>> doesn't not suit `SpotLight`, and I tend to think that the answer is no.
>> 
>> - [X] The inner and outer angles are the "diameter angles" as shown 
>> [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types).
>>   I, personally, find it more intuitive that these are the "radius angles", 
>> so half these angles, as used in the spotlight factor formula. Do you think 
>> I can change this or do you prefer the current definition of the angles?
>> 
>> - [ ] The current implementation uses an ad-hoc direction property (using a 
>> `Point3D`). It crossed my mind that we could use the rotation transforms of 
>> the node to control the direction instead, just like we use the 
>> translation/layout of the node to get the position (there is an internal 
>> Affine3D transform for lights, not sure why `AmbientLight` needs it). 
>> Wouldn't that make more sense? When I rotate the light I would expect to see 
>> a change in direction.
>> 
>> ### Implementation discussion points
>> 
>> - [ ] I've gotten advice from a graphics engineer to treat point lights as 
>> spot lights with a 360 degrees coverage, which simplifies a few places. We 
>> can still try to optimize for a point light by looking at the light 
>> parameters: `falloff = 0` and `outerAngle = 180`. These possible 
>> optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the 
>> pixel/fragment shaders in the form of 3 different ways to compute the 
>> spotlight factor (the `computeLightN` methods). We need to check which of 
>> these give the best results.
>> 
>> ## Performance
>> 
>> Testing 3 point lights and comparing this branch with `master` using a 1000 
>> division sphere, 200 meshes, and 5000 meshes.
>> Using an AMD RX 470 4GB GPU.
>> 
>> In this branch, there is a possible CPU optimization for checking the light 
>> type and using precalculated values (in `D3DMeshView.cc` for d3d and 
>> `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing 
>> the spotlight factor contributions (`computeSpotlightFactor`, 
>> `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out 
>> different branching and shortcuts.
>> 
>> ### Results
>> The CPU "optimizations" made no difference, which is understandable 
>> considering it will not be the bottleneck. We can remove these if we want to 
>> simplify, though maybe if we allow a large number of lights it could make a 
>> difference (I doubt it). I don't have a strong preference either way.
>> 
>> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu).
>> 
>> **Win 10**
>> Compared with the `master` branch, this patch shows 5-10 fps drop in the 
>> mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several 
>> occasions and got different results in terms of absolute numbers, but the 
>> relative performance difference remained more or less the same. Out of the 3 
>> `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no 
>> "optimizations", gives slightly better performance.
>> 
>> **Ubuntu 18**
>> The mesh 200 test always gave 60 fps because it is locked to this fps, so we 
>> can't measure the real GPU performance change.
>> The mesh 5000 test shows 2-6 fps drop from master, with 
>> `computeSpotlightFactor` > `computeSpotlightFactor2`  > 
>> `computeSpotlightFactor3` at in terms of performance (~2 fps difference 
>> each).
>> 
>> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. 
>> `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave 
>> the best performances.
>
> Nir Lisker has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Update documentation

Hello Nir, could you please merge this branch with latest master.

-

PR: https://git.openjdk.java.net/jfx/pull/334

Re: Minimum JDK policy for OpenJFX

[Nir Lisker]

I looked at jextract a while back. I got the impression that it's more
useful when you need to generate new bindings, at the very least because
there are fewer ways to make mistakes. Most of the work on JavaFX has
already been done in this area and the mistakes have been found and fixed
by now, so is there any substantial value in redoing it with jextract?

On Thu, May 20, 2021 at 12:25 AM Ty Young  wrote:

> If you want to learn more about Panama you can read the JEP page:
>
>
> https://openjdk.java.net/jeps/412
>
>
> You can also join the panama-dev list and ask questions:
>
>
> https://mail.openjdk.java.net/mailman/listinfo/panama-dev
>
>
> Biggest things for JavaFX that I can think of is jextract, a tool for
> generating Java headers from a C header, and having all binding code
> written in Java. It may be easier to upgrade to newer GTK versions using
> Panama as there is no C shim required and the bindings are, again,
> generated for you. jextract does have issues, one of which is that any
> binding generated using it are platform-specific even if the library
> itself is cross-platform. You can make bindings by hand that are
> cross-platform if you want, though.
>
>
> Speaking of GTK, when is JavaFX going to support GTK4?
>
>
>
>
> On 5/18/21 4:42 PM, Nir Lisker wrote:
> >> there are some advantages in being able to run with the latest JDK LTS
> >>
> > One *potential* issue with this approach is that LTS is not defined in
> > OpenJDK as far as I know. The LTS versions are a business decision of
> each
> > distributor. For now, they have all aligned on 8, 11, 17, but nothing
> > guarantees that this will stay so. What if different vendors LTS
> different
> > versions? Suppose that Valhalla and Loom add very attractive features in
> > JDK 19 (big performance enhancements, leads to big money savings on
> > hardware, leads to economic incentives to use these, leads to requests to
> > support these), now vendors can declare JDK 19 as LTS, and what will
> JavaFX
> > do?
> > In OpenJDK all versions are treated equally as it is a spec and not a
> > business model. Should JavaFX be coupled to business models? Maybe Gluon
> > has some insights since they give JavaFX LTS support.
> >
> > A second point, as Michael Strauß mentioned, is that maybe we should see
> > what features are going to be delivered in the next versions and judge if
> > there's something attractive enough for library developers to base our
> > decision on. Sealed classes from Amber are certainly one of them. Panama
> > might provide handy features for JavaFX's interfacing with native code,
> > like Foreign Memory Access, though I didn't look into it in detail.
> > Valhalla is certainly too far away to consider, and Loom is rather
> > irrelevant for JavaFX and GUIs in general.
> > If anyone has insights into relevant upcoming features I'll be happy to
> > learn.
> >
> > - Nir
> >
> > On Tue, May 18, 2021 at 6:17 PM Kevin Rushforth <
> kevin.rushfo...@oracle.com>
> > wrote:
> >
> >> A very timely question. I was already planning to raise this as a
> >> discussion after we update our boot JDK to JDK 16 (blocked by the
> >> in-progress gradle 7 update), which I hope to do later this week.
> >>
> >> I think that this is the right time to consider bumping the minimum
> >> required version to run JavaFX 17 to JDK 16, which would allow us to
> >> start using APIs and language features from JDK 12 through JDK 16
> >> inclusive.
> >>
> >> In general, we only guarantee that JavaFX N runs on JDK N-1 or later. In
> >> practice, though, we don't bump it for each release, as there are some
> >> advantages in being able to run with the latest JDK LTS. Since JavaFX 17
> >> will release at roughly the same time as JDK 17 LTS, I can't think of a
> >> good reason to not update our minimum.
> >>
> >> Comments?
> >>
> >> -- Kevin
> >>
> >>
> >> On 5/18/2021 7:59 AM, Michael Strauß wrote:
> >>> Currently, JDK 11 is required for the latest version of OpenJFX. What
> >>> is the policy for bumping this requirement? Does it always correspond
> >>> to the latest JDK LTS release (the next of which will be JDK 17), or
> >>> is it independent from the release cycle of OpenJDK?
> >>
>

Re: [External] : Re: Minimum JDK policy for OpenJFX

[Nir Lisker]

Looks like the new features that we can use are:
- Switch expressions
- Records
- Text blocks
- Pattern matching for instanceof

None of them seem pressing. When we get the more complete set of pattern
matching (with switch, sealed classes, guards...) it will probably be
enough to merit an update.

On Wed, May 19, 2021 at 6:16 PM Kevin Rushforth 
wrote:

> These are all excellent points. I would add that while a new language
> feature would be the biggest reason to update, there could be new JDK API
> that we would want to use as an argument type or return type in a new FX
> API. I'm not aware of any in the JDK 12-16 range (at least not ones that
> don't also have language changes such as records), but it has happened
> before.
>
> So taking all of this into account, it seems that unless someone wants to
> make an argument for a feature (language or API) from JDK 12 or later that
> we need to use in JavaFX 17, it seems unlikely that we will bump the
> minimum.
>
> -- Kevin
>
>
> On 5/19/2021 7:35 AM, Johan Vos wrote:
>
> Hi,
>
> This is an important and good discussion, and I've read a number of valid
> points. To reiterate what I've always stated:
> * we don't want to increase the base (JDK) version just for the sake of
> increasing
> * we don't want to lose significant benefits (or developer productivity)
> by sticking with old versions.
>
> This comes down to the question that is indeed the most important: are
> there *language* features in JDK 12 or higher that would improve the
> quality of OpenJFX? Clearly we're not talking about runtime improvements,
> as it's up to the developer/use to choose a runtime.
>
> Personally, I don't see many possible huge improvements in the JavaFX API
> by using JDK 12+ features, but I might be missing things.
>
> Related to the LTS discussion (disclaimer: just my personal opinion here,
> not an "official" Gluon statement): I don't see that as the primary reason
> for bumping the dependency. The thing we want to avoid though is that there
> is a jump in the required Java SDK inside an LTS family (e.g. JavaFX 11 has
> Java 11 as its base, and JavaFX 11.0.12 will have Java 11 as its base as
> well).
> This might become harder in the future, as I can imagine Valhalla having a
> bigger impact on OpenJFX then e.g. Loom. Hence, in case 17 is an LTS
> version and it starts being based on Java 11, and in case we decide to bump
> the base level for JavaFX 20 to e.g. Java 19, it might become much harder
> to backport issues into the 17-tree.
> In that spirit, it would make sense to bump the version for 17, but it
> seems a bit artificial as the major new language benefits (to OpenJFX) in
> the JDK might occur in between 2 LTS families.
>
> - Johan
>
>
> On Wed, May 19, 2021 at 12:39 AM Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> You raise a good point about whether or not it should matter if a
>> version is (generally considered to be) an LTS release. I wasn't
>> suggesting that we necessarily wait until the next LTS to consider
>> picking up an important new feature, just that it could be one factor. I
>> also would be very interested to hear from Gluon on this point.
>>
>> Your second point is the more interesting one. It comes down to the
>> question of when is there a new feature (or set of new features) that is
>> compelling enough that we want to require that version of the JDK in
>> order to be able to use it.
>>
>> So for this specific discussion: Is there any language feature or API in
>> JDK 12 - 16 that is compelling enough that we would want to bump the JDK
>> in order to be able to use it?
>>
>> -- Kevin
>>
>>
>> On 5/18/2021 2:42 PM, Nir Lisker wrote:
>> >
>> > there are some advantages in being able to run with the latest JDK
>> LTS
>> >
>> >
>> > One *potential* issue with this approach is that LTS is not defined in
>> > OpenJDK as far as I know. The LTS versions are a business decision of
>> > each distributor. For now, they have all aligned on 8, 11, 17, but
>> > nothing guarantees that this will stay so. What if different vendors
>> > LTS different versions? Suppose that Valhalla and Loom add very
>> > attractive features in JDK 19 (big performance enhancements, leads to
>> > big money savings on hardware, leads to economic incentives to use
>> > these, leads to requests to support these), now vendors can declare
>> > JDK 19 as LTS, and what will JavaFX do?
>> > In OpenJDK all versions are treated equally as it is a spec and not a
>> > business model. Should JavaFX be coupled to business models? Maybe
>> > Gluon has some insights since they give JavaFX LTS support.
>> >
>> > A second point, as Michael Strauß mentioned, is that maybe we should
>> > see what features are going to be delivered in the next versions and
>> > judge if there's something attractive enough for library developers to
>> > base our decision on. Sealed classes from Amber are certainly one of
>> > them. Panama might provide handy features for JavaFX's interfacing
>> >