Re: RFR: 8298167: Opacity in WebView not working anymore
On Wed, 11 Jan 2023 07:32:20 GMT, Roman Marchenko wrote: > There was refactoring in WebKit's GraphicsContext class (nativecode) > https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63 > > > GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't > adapted after GraphicsContext's refactoring integration into JFX. As the > result, the methods were not invoked, so TransparencyLayer couldn't be added > to a rendering queue. > > Now the methods are fixed to be used properly in GraphicsContext inheritance > chain. force-pushed to trigger the tests. - PR: https://git.openjdk.org/jfx/pull/992
Re: RFR: 8298167: Opacity in WebView not working anymore [v2]
> There was refactoring in WebKit's GraphicsContext class (nativecode) > https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63 > > > GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't > adapted after GraphicsContext's refactoring integration into JFX. As the > result, the methods were not invoked, so TransparencyLayer couldn't be added > to a rendering queue. > > Now the methods are fixed to be used properly in GraphicsContext inheritance > chain. Roman Marchenko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: Fixed the opacity issue - Changes: https://git.openjdk.org/jfx/pull/992/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=992&range=01 Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/992.diff Fetch: git fetch https://git.openjdk.org/jfx pull/992/head:pull/992 PR: https://git.openjdk.org/jfx/pull/992
RFR: 8298167: Opacity in WebView not working anymore
There was refactoring in WebKit's GraphicsContext class (nativecode) https://github.com/WebKit/WebKit/commit/1733b8bc3dff7595ab8e42561fc0f20a2b8fee63 GraphicsContextJava's methods begin/endPlatformTransparencyLayers weren't adapted after GraphicsContext's refactoring integration into JFX. As the result, the methods were not invoked, so TransparencyLayer couldn't be added to a rendering queue. Now the methods are fixed to be used properly in GraphicsContext inheritance chain. - Commit messages: - Fixed the opacity issue Changes: https://git.openjdk.org/jfx/pull/992/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=992&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298167 Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/992.diff Fetch: git fetch https://git.openjdk.org/jfx pull/992/head:pull/992 PR: https://git.openjdk.org/jfx/pull/992
Re: Windows build fails at MediaCapabilities.cpp(323): error C2327
modules\javafx.web\src\main\native\Source\WebCore\Modules/mediacapabilities/MediaCapabilities.cpp(323): error C2327: 'WebCore::MediaCapabilities::m_encodingTasks': is not a type name, static, or enumerator Looking into it a bit more, it looks as if the compiler is failing to pick up the 'MediaCapabilities.h' header file that defines 'm_encodingTasks', shown below: MediaCapabilities.h https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/Modules/mediacapabilities/MediaCapabilities.h In the build messages, the error occurs right after: > Task :web:compileNativeWin Current settings: Configuration:Release Arch:x86_64 + cmake --build C:/cygwin64/home/john/src/jfx/modules/javafx.web/build/win/Release --config Release -- The messages show the compiler invocation as: C:\PROGRA~1\MICROS~1\2022\COMMUN~1\VC\Tools\MSVC\1434~1.319\bin\Hostx64\x64\cl.exe ... -IC:\cygwin64\home\john\src\jfx\modules\javafx.web\src\main\native\Source\WebCore\Modules\mediacapabilities ... -c C:\cygwin64\home\john\src\jfx\modules\javafx.web\build\win\Release\WebCore\DerivedSources\unified-sources\UnifiedSource-4babe430-14.cpp It's as if the compiler is not picking up the '-I' option to include the header files in the 'mediacapabilities' directory. Unfortunately, I don't have the log files from an earlier working build to see what's different. John
Re: RFR: 8217853: Cleanup in the D3D native pipeline [v11]
On Sun, 25 Dec 2022 04:04:40 GMT, Nir Lisker wrote: >> Refactoring and renaming changes to some of the D3D pipeline files and a few >> changes on the Java side. These are various "leftovers" from previous issues >> that we didn't want to touch at the time in order to confine the scope of >> the changes. They will make future work easier. >> >> Since there are many small changes, I'm giving a full list here: >> >> **Java** >> >> * `NGShape3D.java` >> * Extracted methods to help with the cumbersome lighting loop: one method >> per light type + empty light (reset light) + default point light. This >> section of the code would benefit from the upcoming pattern matching on >> `switch`. >> * Normalized the direction here instead of in the native code. >> * Ambient light is now only set when it exists (and is not black). >> * `NGPointLight,java` - removed unneeded methods that were used by >> `NGShape3D` before the per-lighting methods were extracted (point light >> doesn't need spotlight-specific methods since they each have their own "add" >> method). >> * `NGSpotLight.java` - removed `@Override` annotations as a result of the >> above change. >> >> **Native C++** >> >> * Initialized the class members of `D3DLight`, `D3DMeshView` and >> `D3DPhongMaterial` in the header file instead of a more cumbersome >> initialization in the constructor (this is allowed since C++ 11). >> * `D3DLight` >> * Commented out unused methods. Were they supposed to be used at some >> point? >> * Renamed the `w` component to `lightOn` since it controls the number of >> lights for the special pixel shader variant and having it in the 4th >> position of the color array was confusing. >> * `D3DPhongShader.h` >> * Renamed some of the register constants for more clarity. >> * Moved the ambient light color constant from the vertex shader to the >> pixel shader (see the shader section below). I don't understand the >> calculation of the number of registers in the comment there: "8 ambient >> points + 2 coords = 10". There is 1 ambient light, what are the ambient >> points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it >> is unused. >> * Reduced the number of assigned vertex register for the `VSR_LIGHTS` >> constant since it included both position and color, but color was unused >> there (it was used directly in the pixel shader), so now it's only the >> position. >> * `D3DMeshView.cc` >> * Unified the lighting loop that prepares the lights' 4-vetors that are >> passed to the shaders. >> * Removed the direction normalization as stated in the change for >> `NGShape3D.java`. >> * Reordered the shader constant assignment to be the same order as in >> `D3DPhongShader.h`. >> >> **Native shaders** >> * Renamed many of the variables to what I think are more descriptive names. >> This includes noting in which space they exist as some calculations are done >> in model space, some in world space, and we might need to do some in view >> space. For vectors, also noted if the vector is to or from (`eye` doesn't >> tell me if it's from or to the camera). >> * Commented out many unused functions. I don't know what they are for, so I >> didn't remove them. >> * `vsConstants` >> * Removed the light color from here since it's unused, only the position >> is. >> * Removed the ambient light color constant from here since it's unused, >> and added it to `psConstants` instead. >> * `vs2ps` >> * Removed the ambient color interpolation, which frees a register (no >> change in performance). >> * Simplified the structure (what is `LocalBumpOut` and why is it called >> `light` and contains `LocalBump`?). >> * `Mtl1PS` and `psMath` >> * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they >> are used for better clarity. >> * Moved the lights loop to `Mtl1PS`. The calculation itself remains in >> `psMath`. >> >> No changes in performance were measured and the behavior stayed the same. > > Nir Lisker has updated the pull request incrementally with two additional > commits since the last revision: > > - Changed comment as suggested > - Removed unused fields > Btw, I can confirm that yes, this fixed it for me. Specifically, commit > [55fe2dc](https://github.com/openjdk/jfx/commit/55fe2dc7371f6dcb12c414c5d672728e47e9c504) > has resolved my issue. If you have time, it would be interesting check if it breaks for you by changing the order of the semantics. It might be worth adding a comment there because it's a rather surprising side effect. - PR: https://git.openjdk.org/jfx/pull/789
Re: RFR: 8277848 Binding and Unbinding to List leads to memory leak [v7]
On Fri, 19 Aug 2022 10:40:01 GMT, Florian Kirmaier wrote: >> Making the initial listener of the ListProperty weak fixes the problem. >> The same is fixed for Set and Map. >> Due to a smart implementation, this is done without any performance drawback. >> (The trick is to have an object, which is both the WeakReference and the >> Changelistener) >> By implying the same trick to the InvalidationListener, this should even >> improve the performance of the collection properties. > > Florian Kirmaier 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 seven additional > commits since the last revision: > > - Merge remote-tracking branch 'origjfx/master' into > JDK-8277848-list-binding-leak > - JDK-8277848 >Added tests to ensure no premature garbage collection is happening. > - JDK-8277848 >Added 3 more tests to verify that a bug discussed in the PR does not > appear. > - JDK-8277848 >Added the 3 requests whitespaces > - JDK-8277848 >Further optimization based code review. >This Bugfix should now event improve the performance > - JDK-8277848 >Added missing change > - JDK-8277848 >Fixed memoryleak, when binding and unbinding a ListProperty. The same was > fixed for SetProperty and MapProperty. The patch looks good and fixes the bug. - Marked as reviewed by mstrauss (Committer). PR: https://git.openjdk.org/jfx/pull/689
Re: RFR: 8267546: Add CSS themes as a first-class concept [v2]
On Fri, 11 Nov 2022 01:11:36 GMT, Michael Strauß wrote:
>> modules/javafx.graphics/src/main/java/javafx/application/PlatformPreferences.java
>> line 117:
>>
>>> 115: * @since 20
>>> 116: */
>>> 117: public interface PlatformPreferences extends Map {
>>
>> Are you sure it is a good idea to expose these as a `Map`? It seems to me
>> that this isn't that good a practice any more to have classes implement or
>> extend lists/maps/sets as they pull in a huge amount of API surface that is
>> mostly useless or too general for the class's purpose.
>>
>> The addition of the listener management methods also has me wondering, as
>> `ObservableMap` does something similar.
>
> All of the mutating methods are useless, since the implementation always
> returns a read-only map. However, the alternative would be to duplicate APIs
> to enumerate and inspect the contents of the `PlatformPreferences` map
> (applications might want to show a list of available preferences). I'm not
> sure that's preferable, mostly because `PlatformPreferences` _does_ represent
> a mapping of keys to values.
>
> It's true that listener management makes it look like an `ObservableMap`. The
> difference is that `ObservableMap` doesn't support batch change
> notifications, which the current implementation relies on to minimize the
> number of style theme resets. Of course, that could be solved in a different
> way.
> The addition of the listener management methods also has me wondering, as
> `ObservableMap` does something similar.
I've switched to using `ObservableMap`.
-
PR: https://git.openjdk.org/jfx/pull/511
Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v9]
> This pull request allows for reproducible builds of JavaFX on Linux, macOS, > and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For > example, the following commands create a reproducible build: > > > $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) > $ bash gradlew sdk jmods javadoc > $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod > > > The three commands: > > 1. set the build timestamp to the date of the latest source code change, > 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and > 3. recreate the JMOD files with stable file modification times and ordering. > > The third command won't be necessary once Gradle can build the JMOD archives > or the `jmod` tool itself has the required support. For more information on > the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more > information on the command to recreate the JMOD files, see the > [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for > reproducible builds in JavaFX 17 and consider making them the default in > JavaFX 18. > > Fixes > > There are at least four sources of non-determinism in the JavaFX builds: > > 1. Build timestamp > > The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module > stores the time of the build. Furthermore, for builds that don't run on the > Hudson continuous integration tool, the class adds the build time to the > system property `javafx.runtime.version`. > > 2. Modification times > > The JAR, JMOD, and ZIP archives store the modification time of each file. > > 3. File ordering > > The JAR, JMOD, and ZIP archives store their files in the order returned > by the file system. The native shared libraries also store their object files > in the order returned by the file system. Most file systems, though, do not > guarantee the order of a directory's file listing. > > 4. Build path > > The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics > module stores the absolute path of its `.css` input file in the corresponding > `.bss` output file, which is then included in the JavaFX Controls module. > > This pull request modifies the Gradle and Groovy build files to fix the first > three sources of non-determinism. A later pull request can modify the Java > files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge branch 'master' into allow-reproducible-builds - Add '--date' argument for deterministic JMOD files - Merge branch 'master' into allow-reproducible-builds - Merge branch 'master' into allow-reproducible-builds - Comment out 'jmod --date' until building on JDK 19 Support for the 'jmod --date' option was added to JDK 19 starting with the 19+2 early-access build, and it was backported to JDK 17 starting with release 17.0.3. It is not available in JDK 18. - Merge 'master' into allow-reproducible-builds - Make minimal changes for new '--date' option - Add new '--date' option to JMOD task - Add '--source-date' option to JMOD task - Get build timestamp in UTC and set ZIP timestamps Create the build timestamp as a zoned date and time in UTC instead of a local date and time. If SOURCE_DATE_EPOCH is defined, set the last modification time of ZIP and JAR entries to the local date and time in UTC of the instant defined by SOURCE_DATE_EPOCH. Add a comment as a reminder to make JMOD files deterministic when the following enhancements are complete: * Enable deterministic file content ordering for Jar and Jmod https://bugs.openjdk.java.net/browse/JDK-8276764 https://github.com/openjdk/jdk/pull/6395 * Enable jar and jmod to produce deterministic timestamped content https://bugs.openjdk.java.net/browse/JDK-8276766 https://github.com/openjdk/jdk/pull/6481 - ... and 8 more: https://git.openjdk.org/jfx/compare/4a278013...0a3dda22 - Changes: https://git.openjdk.org/jfx/pull/446/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=446&range=08 Stats: 145 lines in 7 files changed: 115 ins; 13 del; 17 mod Patch: https://git.openjdk.org/jfx/pull/446.diff Fetch: git fetch https://git.openjdk.org/jfx pull/446/head:pull/446 PR: https://git.openjdk.org/jfx/pull/446
Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v8]
On Tue, 3 Jan 2023 00:21:53 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives >> or the `jmod` tool itself has the required support. For more information on >> the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more >> information on the command to recreate the JMOD files, see the >> [`strip-nondeterminism`][2] repository. I'd like to propose that we allow >> for reproducible builds in JavaFX 17 and consider making them the default in >> JavaFX 18. >> >> Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module >> stores the time of the build. Furthermore, for builds that don't run on the >> Hudson continuous integration tool, the class adds the build time to the >> system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned >> by the file system. The native shared libraries also store their object >> files in the order returned by the file system. Most file systems, though, >> do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics >> module stores the absolute path of its `.css` input file in the >> corresponding `.bss` output file, which is then included in the JavaFX >> Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the >> first three sources of non-determinism. A later pull request can modify the >> Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 17 commits: > > - Add '--date' argument for deterministic JMOD files > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - Comment out 'jmod --date' until building on JDK 19 > >Support for the 'jmod --date' option was added to JDK 19 starting >with the 19+2 early-access build, and it was backported to JDK 17 >starting with release 17.0.3. It is not available in JDK 18. > - Merge 'master' into allow-reproducible-builds > - Make minimal changes for new '--date' option > - Add new '--date' option to JMOD task > - Add '--source-date' option to JMOD task > - Get build timestamp in UTC and set ZIP timestamps > >Create the build timestamp as a zoned date and time in UTC instead >of a local date and time. If SOURCE_DATE_EPOCH is defined, set the >last modification time of ZIP and JAR entries to the local date and >time in UTC of the instant defined by SOURCE_DATE_EPOCH. > >Add a comment as a reminder to make JMOD files deterministic when >the following enhancements are complete: > >* Enable deterministic file content ordering for Jar and Jmod > https://bugs.openjdk.java.net/browse/JDK-8276764 > https://github.com/openjdk/jdk/pull/6395 > >* Enable jar and jmod to produce deterministic timestamped content > https://bugs.openjdk.java.net/browse/JDK-8276766 > https://github.com/openjdk/jdk/pull/6481 > - Merge branch 'master' into allow-reproducible-builds > - ... and 7 more: https://git.openjdk.org/jfx/compare/a35c3bf7...1e4c083b I tested the Linux "Release" build again now that pull request #989 is integrated. The updated results are shown below: | System | Develop | Actions | Release | Notes| |:---:|:---:|:---:|:---:| | | Linux |✔|✔|✔| | | macOS |✔|❓|❓| Some shared libraries differ | | Windows |✔|✔|❌| Release build failed | where ✔, ❓, and ❌ have the meanings described earlier. I'll test the Windows "Release" build next to see whether it's stil
Re: RFR: 8299681: Change JavaFX release version to 21
On Tue, 10 Jan 2023 00:37:24 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 21. I will integrate this to `master` as > part of forking the `jfx20` stabilization branch, which is scheduled for > Thursday, January 12, 2023 at 16:00 UTC. checked against the older PR https://github.com/openjdk/jfx/pull/820/files - Marked as reviewed by angorya (Committer). PR: https://git.openjdk.org/jfx/pull/990
Integrated: 8293119: Additional constrained resize policies for Tree/TableView
On Mon, 12 Sep 2022 21:58:47 GMT, Andy Goryachev wrote: > The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in > [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810). > > We propose to address all these issues by replacing the old column resize > algorithm with a different one, which not only honors all the constraints > when resizing, but also provides 4 different resize modes similar to > JTable's. The new implementation brings changes to the public API for > Tree/TableView and ResizeFeaturesBase classes. Specifically: > > - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase > class > - provide an out-of-the box implementation via > javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: > AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, > AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS > - add corresponding public static constants to Tree/TableView > - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to > AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss) > - add getContentWidth() and setColumnWidth(TableColumnBase col, double > width) methods to ResizeFeatureBase > - suppress the horizontal scroll bar when resize policy is instanceof > ConstrainedColumnResizeBase > - update javadoc > > > Notes > > 1. The current resize policies' toString() methods return > "unconstrained-resize" and "constrained-resize", used by the skin base to set > a pseudostate. All constrained policies that extend > ConstrainedColumnResizeBase will return "constrained-resize" value. > 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen > instead of a marker interface is exactly for its toString() method which > supplies "constrained-resize" value. The implementors might choose to use a > different value, however they must ensure the stylesheet contains the same > adjustments for the new policy as those made in modena.css for > "constrained-resize" value. This pull request has now been integrated. Changeset: 1ac97fc5 Author:Andy Goryachev URL: https://git.openjdk.org/jfx/commit/1ac97fc566591e413d67bc7230ea0b351271d7a8 Stats: 2629 lines in 16 files changed: 2388 ins; 226 del; 15 mod 8293119: Additional constrained resize policies for Tree/TableView Reviewed-by: aghaisas, kcr - PR: https://git.openjdk.org/jfx/pull/897
Integrated: 8217853: Cleanup in the D3D native pipeline
On Mon, 2 May 2022 16:05:08 GMT, Nir Lisker wrote: > Refactoring and renaming changes to some of the D3D pipeline files and a few > changes on the Java side. These are various "leftovers" from previous issues > that we didn't want to touch at the time in order to confine the scope of the > changes. They will make future work easier. > > Since there are many small changes, I'm giving a full list here: > > **Java** > > * `NGShape3D.java` > * Extracted methods to help with the cumbersome lighting loop: one method > per light type + empty light (reset light) + default point light. This > section of the code would benefit from the upcoming pattern matching on > `switch`. > * Normalized the direction here instead of in the native code. > * Ambient light is now only set when it exists (and is not black). > * `NGPointLight,java` - removed unneeded methods that were used by > `NGShape3D` before the per-lighting methods were extracted (point light > doesn't need spotlight-specific methods since they each have their own "add" > method). > * `NGSpotLight.java` - removed `@Override` annotations as a result of the > above change. > > **Native C++** > > * Initialized the class members of `D3DLight`, `D3DMeshView` and > `D3DPhongMaterial` in the header file instead of a more cumbersome > initialization in the constructor (this is allowed since C++ 11). > * `D3DLight` > * Commented out unused methods. Were they supposed to be used at some point? > * Renamed the `w` component to `lightOn` since it controls the number of > lights for the special pixel shader variant and having it in the 4th position > of the color array was confusing. > * `D3DPhongShader.h` > * Renamed some of the register constants for more clarity. > * Moved the ambient light color constant from the vertex shader to the > pixel shader (see the shader section below). I don't understand the > calculation of the number of registers in the comment there: "8 ambient > points + 2 coords = 10". There is 1 ambient light, what are the ambient > points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it > is unused. > * Reduced the number of assigned vertex register for the `VSR_LIGHTS` > constant since it included both position and color, but color was unused > there (it was used directly in the pixel shader), so now it's only the > position. > * `D3DMeshView.cc` > * Unified the lighting loop that prepares the lights' 4-vetors that are > passed to the shaders. > * Removed the direction normalization as stated in the change for > `NGShape3D.java`. > * Reordered the shader constant assignment to be the same order as in > `D3DPhongShader.h`. > > **Native shaders** > * Renamed many of the variables to what I think are more descriptive names. > This includes noting in which space they exist as some calculations are done > in model space, some in world space, and we might need to do some in view > space. For vectors, also noted if the vector is to or from (`eye` doesn't > tell me if it's from or to the camera). > * Commented out many unused functions. I don't know what they are for, so I > didn't remove them. > * `vsConstants` > * Removed the light color from here since it's unused, only the position is. > * Removed the ambient light color constant from here since it's unused, and > added it to `psConstants` instead. > * `vs2ps` > * Removed the ambient color interpolation, which frees a register (no > change in performance). > * Simplified the structure (what is `LocalBumpOut` and why is it called > `light` and contains `LocalBump`?). > * `Mtl1PS` and `psMath` > * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are > used for better clarity. > * Moved the lights loop to `Mtl1PS`. The calculation itself remains in > `psMath`. > > No changes in performance were measured and the behavior stayed the same. This pull request has now been integrated. Changeset: 4a278013 Author:Nir Lisker URL: https://git.openjdk.org/jfx/commit/4a2780134b88e86e437ae2bdffe06b145788e61d Stats: 685 lines in 22 files changed: 232 ins; 227 del; 226 mod 8217853: Cleanup in the D3D native pipeline Reviewed-by: arapte, kcr - PR: https://git.openjdk.org/jfx/pull/789
Re: RFR: 8217853: Cleanup in the D3D native pipeline [v11]
On Sun, 25 Dec 2022 04:04:40 GMT, Nir Lisker wrote: >> Refactoring and renaming changes to some of the D3D pipeline files and a few >> changes on the Java side. These are various "leftovers" from previous issues >> that we didn't want to touch at the time in order to confine the scope of >> the changes. They will make future work easier. >> >> Since there are many small changes, I'm giving a full list here: >> >> **Java** >> >> * `NGShape3D.java` >> * Extracted methods to help with the cumbersome lighting loop: one method >> per light type + empty light (reset light) + default point light. This >> section of the code would benefit from the upcoming pattern matching on >> `switch`. >> * Normalized the direction here instead of in the native code. >> * Ambient light is now only set when it exists (and is not black). >> * `NGPointLight,java` - removed unneeded methods that were used by >> `NGShape3D` before the per-lighting methods were extracted (point light >> doesn't need spotlight-specific methods since they each have their own "add" >> method). >> * `NGSpotLight.java` - removed `@Override` annotations as a result of the >> above change. >> >> **Native C++** >> >> * Initialized the class members of `D3DLight`, `D3DMeshView` and >> `D3DPhongMaterial` in the header file instead of a more cumbersome >> initialization in the constructor (this is allowed since C++ 11). >> * `D3DLight` >> * Commented out unused methods. Were they supposed to be used at some >> point? >> * Renamed the `w` component to `lightOn` since it controls the number of >> lights for the special pixel shader variant and having it in the 4th >> position of the color array was confusing. >> * `D3DPhongShader.h` >> * Renamed some of the register constants for more clarity. >> * Moved the ambient light color constant from the vertex shader to the >> pixel shader (see the shader section below). I don't understand the >> calculation of the number of registers in the comment there: "8 ambient >> points + 2 coords = 10". There is 1 ambient light, what are the ambient >> points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it >> is unused. >> * Reduced the number of assigned vertex register for the `VSR_LIGHTS` >> constant since it included both position and color, but color was unused >> there (it was used directly in the pixel shader), so now it's only the >> position. >> * `D3DMeshView.cc` >> * Unified the lighting loop that prepares the lights' 4-vetors that are >> passed to the shaders. >> * Removed the direction normalization as stated in the change for >> `NGShape3D.java`. >> * Reordered the shader constant assignment to be the same order as in >> `D3DPhongShader.h`. >> >> **Native shaders** >> * Renamed many of the variables to what I think are more descriptive names. >> This includes noting in which space they exist as some calculations are done >> in model space, some in world space, and we might need to do some in view >> space. For vectors, also noted if the vector is to or from (`eye` doesn't >> tell me if it's from or to the camera). >> * Commented out many unused functions. I don't know what they are for, so I >> didn't remove them. >> * `vsConstants` >> * Removed the light color from here since it's unused, only the position >> is. >> * Removed the ambient light color constant from here since it's unused, >> and added it to `psConstants` instead. >> * `vs2ps` >> * Removed the ambient color interpolation, which frees a register (no >> change in performance). >> * Simplified the structure (what is `LocalBumpOut` and why is it called >> `light` and contains `LocalBump`?). >> * `Mtl1PS` and `psMath` >> * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they >> are used for better clarity. >> * Moved the lights loop to `Mtl1PS`. The calculation itself remains in >> `psMath`. >> >> No changes in performance were measured and the behavior stayed the same. > > Nir Lisker has updated the pull request incrementally with two additional > commits since the last revision: > > - Changed comment as suggested > - Removed unused fields LGTM - Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/789
Re: RFR: 8299681: Change JavaFX release version to 21
On Tue, 10 Jan 2023 00:37:24 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 21. I will integrate this to `master` as > part of forking the `jfx20` stabilization branch, which is scheduled for > Thursday, January 12, 2023 at 16:00 UTC. Marked as reviewed by arapte (Reviewer). - PR: https://git.openjdk.org/jfx/pull/990
Re: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v33]
On Mon, 9 Jan 2023 23:08:02 GMT, Andy Goryachev wrote: >> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in >> [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810). >> >> We propose to address all these issues by replacing the old column resize >> algorithm with a different one, which not only honors all the constraints >> when resizing, but also provides 4 different resize modes similar to >> JTable's. The new implementation brings changes to the public API for >> Tree/TableView and ResizeFeaturesBase classes. Specifically: >> >> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase >> class >> - provide an out-of-the box implementation via >> javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: >> AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, >> AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS >> - add corresponding public static constants to Tree/TableView >> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to >> AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss) >> - add getContentWidth() and setColumnWidth(TableColumnBase col, double >> width) methods to ResizeFeatureBase >> - suppress the horizontal scroll bar when resize policy is instanceof >> ConstrainedColumnResizeBase >> - update javadoc >> >> >> Notes >> >> 1. The current resize policies' toString() methods return >> "unconstrained-resize" and "constrained-resize", used by the skin base to >> set a pseudostate. All constrained policies that extend >> ConstrainedColumnResizeBase will return "constrained-resize" value. >> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen >> instead of a marker interface is exactly for its toString() method which >> supplies "constrained-resize" value. The implementors might choose to use a >> different value, however they must ensure the stylesheet contains the same >> adjustments for the new policy as those made in modena.css for >> "constrained-resize" value. > > Andy Goryachev has updated the pull request incrementally with one additional > commit since the last revision: > > 8293119: whitespace I have tested on macOS. This looks good! - Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/897
Integrated: 8282386: JavaFX media stubs rely on libav.org
On Thu, 5 Jan 2023 14:11:10 GMT, Johan Vos wrote: > Retrieve libav sources from github. > Fix JDK-8282386 This pull request has now been integrated. Changeset: 357cd856 Author:Johan Vos URL: https://git.openjdk.org/jfx/commit/357cd8563bd6ca47afd28dd1481afbe2d2458827 Stats: 21 lines in 2 files changed: 15 ins; 0 del; 6 mod 8282386: JavaFX media stubs rely on libav.org Reviewed-by: jgneff, kcr, almatvee - PR: https://git.openjdk.org/jfx/pull/989
