Re: RFR: 8234920: Add SpotLight to the selection of 3D light types [v26]
> 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? > > - [x] 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: Fixed method call in glsl shaders - Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/c9fb2452..5c775341 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=25 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=24-25 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334
Integrated: 8268219: hlsprogressbuffer should provide PTS after GStreamer update
On Sat, 12 Jun 2021 00:10:55 GMT, Alexander Matveev wrote: > - Reverted JDK-8268152 fix in gstbaseparse.c, since it is no longer needed. > - Our hlsprogressbuffer outputs buffers in time format, but without any PTS. > After GStreamer update mpregparser no longer tries to figure out timestamps > if stream in time format and it will assume that upstream provides > timestamps. Fixed by providing starting timestamp at the beginning or after > seek. In this case mpegparser able to figure out timestamps and will provide > them for each buffer downstream. > - Segment start was also incorrect it should be seek position, otherwise > after seek playback waits for seek time. For example if we seek to 2 min, > mediaplayer hangs for 2 min and only after that resumes playback. I think it > worked before, since mpegparser handled PTS before. This pull request has now been integrated. Changeset: 98138c84 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/98138c84a7f286731ad12dd5c533cd3fa265bf56 Stats: 19 lines in 2 files changed: 13 ins; 4 del; 2 mod 8268219: hlsprogressbuffer should provide PTS after GStreamer update Reviewed-by: kcr, arapte - PR: https://git.openjdk.java.net/jfx/pull/532
Re: RFR: 8234920: Add SpotLight to the selection of 3D light types [v25]
On Wed, 16 Jun 2021 14:08:24 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? >> >> - [x] 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: > > Fix for glsl shaders The glsl `computeLight` methods are still calling the now-commented-out alternative shaders, so it fails at load time. See, for example, [main1Light.frag#L129](https://github.com/openjdk/jfx/blob/c9fb2452cffad5e9256e4ef7dbb733a69a655dac/modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main1Light.frag#L129). The rest of the changes look fine. - PR: https://git.openjdk.java.net/jfx/pull/334
Re: Command Line Tools for Xcode 12.4 → 12.5
Our production builds use Xcode 12.4 [1]. The GitHub Actions build haven't caught up yet. See JDK-8266218 [2]. -- Kevin [1] https://github.com/openjdk/jfx/blob/master/build.properties#L93 [2] https://bugs.openjdk.java.net/browse/JDK-8266218 On 6/16/2021 10:54 AM, John Neffenger wrote: On 6/16/21 10:21 AM, John Neffenger wrote: 4. Finally look up what the GitHub Actions are using (12.4). Oops, make that "Finally look up what the project uses (12.4)." For the record, our GitHub Actions use Xcode_11.3.1. [1] John [1]: https://github.com/openjdk/jfx/blob/master/.github/workflows/submit.yml#L202
Re: Command Line Tools for Xcode 12.4 → 12.5
On 6/16/21 10:21 AM, John Neffenger wrote: 4. Finally look up what the GitHub Actions are using (12.4). Oops, make that "Finally look up what the project uses (12.4)." For the record, our GitHub Actions use Xcode_11.3.1. [1] John [1]: https://github.com/openjdk/jfx/blob/master/.github/workflows/submit.yml#L202
Re: Command Line Tools for Xcode 12.4 → 12.5
On 6/16/21 9:56 AM, Philip Race wrote: 1) Don't let macOS upgrade my xcode tools automatically Lesson learned! But then there's that annoying red badge on your System Preferences forever. :-) Actually, it was worse, and went more like this (just in case any else gets led off-course by the error message below): 1. Naively download the latest CLTools 12.5. 2. See the following error message and think I need the full Xcode: xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance That is a red herring. It's just the build testing whether the full Xcode is installed by running the command 'xcodebuild -version -showsdks'. When that command fails, the build runs 'xcrun --show-sdk-path' and continues without problems. 3. Download and install the full Xcode 12.5, and it still fails! 4. Finally look up what the GitHub Actions are using (12.4). 5. Download and install CLTools 12.4 -- works! 6. Uninstall the 11-GB constantly-updating Xcode app. John
Re: Command Line Tools for Xcode 12.4 → 12.5
FWIW this is why I 1) Don't let macOS upgrade my xcode tools automatically 2) Let someone else trail blaze :-), unless I am ready to do the work to make the upgraded tools work. -phil. On 6/16/21 9:27 AM, John Neffenger wrote: Just a heads-up about using the latest Xcode 12.5 ...
Re: Command Line Tools for Xcode 12.4 → 12.5
Can you file a bug? We will take a look at it. Thanks. -- Kevin On 6/16/2021 9:27 AM, John Neffenger wrote: Just a heads-up about using the latest Xcode 12.5 ... I use the Command Line Tools for Xcode 12.4 (at 431 MB) to build JavaFX on macOS as an alternative to the full Xcode package (at 11.86 GB). Thank you, Arunprasad Rajkumar! [1] Then Apple Software Update installed the latest Command Line Tools for Xcode 12.5, and my builds of JavaFX with WebKit started failing. You can find out what version you're using with the command: $ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables package-id: com.apple.pkg.CLTools_Executables version: 12.5.0.0.1.1617976050 volume: / location: / install-time: 1623800794 groups: com.apple.FindSystemFiles.pkg-group You can download and revert to the 12.4 release below: More Downloads https://developer.apple.com/download/all/?q=12.4 Note that the OpenJFX project uses version 12.4 (build.properties): jfx.build.macosx.xcode.version=Xcode12.4+1.0 The errors using version 12.5 start with: .../modules/javafx.web/src/main/native/Source/ThirdParty/ sqlite/./version:1:1: error: expected unqualified-id /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ usr/include/c++/v1/cstddef:49:9: error: no member named 'ptrdiff_t' in the global namespace and end with: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /var/folders/... clang: note: diagnostic msg: /var/folders/... clang: note: diagnostic msg: Crash backtrace is located in clang: note: diagnostic msg: /Users/john/Library/Logs/ DiagnosticReports/clang__.crash clang: note: diagnostic msg: (choose the .crash file that corresponds to your crash) clang: note: diagnostic msg: John [1]: https://github.com/openjdk/jfx/pull/13
Command Line Tools for Xcode 12.4 → 12.5
Just a heads-up about using the latest Xcode 12.5 ... I use the Command Line Tools for Xcode 12.4 (at 431 MB) to build JavaFX on macOS as an alternative to the full Xcode package (at 11.86 GB). Thank you, Arunprasad Rajkumar! [1] Then Apple Software Update installed the latest Command Line Tools for Xcode 12.5, and my builds of JavaFX with WebKit started failing. You can find out what version you're using with the command: $ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables package-id: com.apple.pkg.CLTools_Executables version: 12.5.0.0.1.1617976050 volume: / location: / install-time: 1623800794 groups: com.apple.FindSystemFiles.pkg-group You can download and revert to the 12.4 release below: More Downloads https://developer.apple.com/download/all/?q=12.4 Note that the OpenJFX project uses version 12.4 (build.properties): jfx.build.macosx.xcode.version=Xcode12.4+1.0 The errors using version 12.5 start with: .../modules/javafx.web/src/main/native/Source/ThirdParty/ sqlite/./version:1:1: error: expected unqualified-id /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ usr/include/c++/v1/cstddef:49:9: error: no member named 'ptrdiff_t' in the global namespace and end with: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /var/folders/... clang: note: diagnostic msg: /var/folders/... clang: note: diagnostic msg: Crash backtrace is located in clang: note: diagnostic msg: /Users/john/Library/Logs/ DiagnosticReports/clang__.crash clang: note: diagnostic msg: (choose the .crash file that corresponds to your crash) clang: note: diagnostic msg: John [1]: https://github.com/openjdk/jfx/pull/13
Re: RFR: 8234920: Add SpotLight to the selection of 3D light types [v24]
On Mon, 14 Jun 2021 01:06:25 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? >> >> - [x] 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: > > Updated links in glsl shaders Thanks for the debugging, Kevin! In the HLSL shader these are already `in out` variables, so no changes there. I commented out the less performant methods. - PR: https://git.openjdk.java.net/jfx/pull/334
Re: RFR: 8234920: Add SpotLight to the selection of 3D light types [v25]
> 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? > > - [x] 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: Fix for glsl shaders - Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/96e4e5ff..c9fb2452 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=24 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=23-24 Stats: 28 lines in 4 files changed: 25 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334
Re: RFR: 8234920: Add SpotLight to the selection of 3D light types [v24]
On Tue, 15 Jun 2021 18:57:09 GMT, Kevin Rushforth wrote: > When I apply that fix it works fine for me on my older MacBook. With the change, It works fine on my mac machine too. - PR: https://git.openjdk.java.net/jfx/pull/334
Re: RFR: 8268219: hlsprogressbuffer should provide PTS after GStreamer update
On Sat, 12 Jun 2021 00:10:55 GMT, Alexander Matveev wrote: > - Reverted JDK-8268152 fix in gstbaseparse.c, since it is no longer needed. > - Our hlsprogressbuffer outputs buffers in time format, but without any PTS. > After GStreamer update mpregparser no longer tries to figure out timestamps > if stream in time format and it will assume that upstream provides > timestamps. Fixed by providing starting timestamp at the beginning or after > seek. In this case mpegparser able to figure out timestamps and will provide > them for each buffer downstream. > - Segment start was also incorrect it should be seek position, otherwise > after seek playback waits for seek time. For example if we seek to 2 min, > mediaplayer hangs for 2 min and only after that resumes playback. I think it > worked before, since mpegparser handled PTS before. Looks good to me, verified on macOS Mojave 10.14.6. - Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/532
Re: RFR: 8267551: Support loading images from inline data-URIs [v19]
On Mon, 14 Jun 2021 08:50:25 GMT, Michael Strauß wrote: >> 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 incrementally with one additional > commit since the last revision: > > changes Looks good to me too. - Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/508
