Re: RFR: 8283218: Update GStreamer to 1.20.1
On Fri, 8 Apr 2022 06:49:59 GMT, Alexander Matveev wrote: > - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. > - No changes to our code, except in GstAudioSpectrum.cpp > g_atomic_pointer_compare_and_exchange() was changed to > g_atomic_pointer_set(). For some reason I was not able to get code compiled > with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do > not see a need to use g_atomic_pointer_compare_and_exchange(), since > m_pHolder always equals to old_holder. > - Tested on all platforms with all supported media streams. This still uses the system Glib library on Linux, right? What Linux platforms have you tried this on? It fails for me on my local Ubuntu 16.04 system. In file included from ../../../gstreamer-lite/gstreamer/gst/gstbuffer.c:137: ../../../gstreamer-lite/gstreamer/gst/gstbuffer.c: In function 'gst_buffer_new_m emdup': ../../../gstreamer-lite/gstreamer/gst/glib-compat-private.h:34:90: error: implicit declaration of function 'g_abort'; did you mean 'abort'? [-Werror=implicit-function-declaration] 34 | #define g_memdup2(ptr,sz) ((G_LIKELY(((guint64)(sz)) < G_MAXUINT)) ? g_memdup(ptr,sz) : (g_abort(),NULL)) | ^~~ We compile with `-Werror=implicit-function-declaration`, so this fails the build. - PR: https://git.openjdk.java.net/jfx/pull/768
Integrated: 8282054: Mediaplayer not working with HTTP Live Stream link with query parameter appended with file extension m3u8
On Fri, 11 Mar 2022 03:01:39 GMT, Alexander Matveev wrote: > - Problem was that our code which checks if URI ends with file extension was > not considering that URI can have query parameters. Fixed by checking URI > path, instead of actual URI. > - Also, creation of HLS Connection holder was missing checking for mimetype, > since we do support URI without extensions as long as they provide correct > mimetype. > - Added #EXTM3U to file signature check in case if extension and mimetype > checks failed to determine stream type. All playlists of HLS based on spec > should start with #EXTM3U. For some reason this particular stream has > mimetype of "audio/x-mpegurl" and it is not mimetype from spec. Based on spec > it should be "audio/mpegurl". Thus check for signature was added in case if > URI does not use extension and has unsupported mimetype. > > Note: audio will not work on Windows and Linux for stream provided in this > bug report due to provided example uses separate audio stream via EXT-X-MEDIA > tag and it is not supported. I filed separate issue for this. This pull request has now been integrated. Changeset: d1110f47 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/d1110f479567c314ecb6848700bcf4552509d7e9 Stats: 65 lines in 2 files changed: 27 ins; 3 del; 35 mod 8282054: Mediaplayer not working with HTTP Live Stream link with query parameter appended with file extension m3u8 Reviewed-by: kcr, arapte - PR: https://git.openjdk.java.net/jfx/pull/750
Re: RFR: 8283402: Update to gcc 11.2 on Linux [v2]
> This patch updates the compiler to gcc 11.2 on Linux, in order to match JDK > 17 -- see [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). > > I ran a full build and test, including media and WebKit. Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into 8283402-gcc-11.2 - 8283402: Update to gcc 11.2 on Linux - Changes: https://git.openjdk.java.net/jfx/pull/761/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=761=01 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/761.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/761/head:pull/761 PR: https://git.openjdk.java.net/jfx/pull/761
Integrated: 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows
On Sat, 2 Apr 2022 17:34:46 GMT, Kevin Rushforth wrote: > This patch updates the compiler to Visual Studio 2022 version 17.1.0 on > Windows, in order to match JDK 19 -- see > [JDK-8283723](https://bugs.openjdk.java.net/browse/JDK-8283723). > > I ran a full build and test, including media and WebKit. This pull request has now been integrated. Changeset: 6d126382 Author:Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/6d126382ddd59757081a866517c36ff09ba20125 Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows Reviewed-by: arapte, sykora - PR: https://git.openjdk.java.net/jfx/pull/766
Re: RFR: 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows
On Sat, 2 Apr 2022 17:34:46 GMT, Kevin Rushforth wrote: > This patch updates the compiler to Visual Studio 2022 version 17.1.0 on > Windows, in order to match JDK 19 -- see > [JDK-8283723](https://bugs.openjdk.java.net/browse/JDK-8283723). > > I ran a full build and test, including media and WebKit. Successfully managed to run a build and test with VS 2022 17.1.0. - Marked as reviewed by sykora (Author). PR: https://git.openjdk.java.net/jfx/pull/766
Re: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4]
On Wed, 30 Mar 2022 13:27:40 GMT, Johan Vos wrote: >> When the size of a ListCell is changed and a scrollTo method is invoked >> without having a layout calculation in between, the old (wrong) size is used >> to calculcate the total estimate. This happens e.g. when the size is changed >> in the `updateItem` method. >> This PR will immediately resize the cell and sets the new value in the cache >> containing the cellsizes. > > Johan Vos has updated the pull request incrementally with one additional > commit since the last revision: > > Don't shift cells if we are already showing the lowest index cell. After some investigating, it also doesn't properly scroll to the Bottom. I've added a minimal modified button to the TestApplication. https://user-images.githubusercontent.com/6547435/162963628-41daf63b-755d-449a-be85-ca0aa0fd9d15.png;> Is this conceptional doable, to get properly working scrollTo implementation for varying cell sizes? - PR: https://git.openjdk.java.net/jfx/pull/712
Re: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling
On Wed, 16 Mar 2022 13:01:45 GMT, Robert Lichtenberger wrote: >> Might make sense to also adjust the TreeTableView sizing implementation? > >> Might make sense to also adjust the TreeTableView sizing implementation? > > Yes I think that may be a good idea. True to the idea of specific, narrow > commits I've not integrated this into this PR but would be willing to open a > new issue / produce a separate PR for TreeTableView. @effad Do you have time and interest to take a look at this for the `TreeTableView` as well? Just asking as otherwise I will have a look :) - PR: https://git.openjdk.java.net/jfx/pull/757
Re: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4]
On Wed, 30 Mar 2022 13:27:40 GMT, Johan Vos wrote: >> When the size of a ListCell is changed and a scrollTo method is invoked >> without having a layout calculation in between, the old (wrong) size is used >> to calculcate the total estimate. This happens e.g. when the size is changed >> in the `updateItem` method. >> This PR will immediately resize the cell and sets the new value in the cache >> containing the cellsizes. > > Johan Vos has updated the pull request incrementally with one additional > commit since the last revision: > > Don't shift cells if we are already showing the lowest index cell. I've added another testbutton to the testclass. When we jump to somewhere in the middle, the selected index is not at the top, but somewhere else. Depending on the application, this can be quite a bit. In the affected application - it sometimes still jumps to places closer to the wrong cell compared to the right cell. The cell #2 should be at the top, but isnt. https://user-images.githubusercontent.com/6547435/162953335-39d40eed-35a7-4728-912b-18a8acce5256.png;> - PR: https://git.openjdk.java.net/jfx/pull/712
Re: RFR: 8282054: Mediaplayer not working with HTTP Live Stream link with query parameter appended with file extension m3u8
On Fri, 11 Mar 2022 03:01:39 GMT, Alexander Matveev wrote: > - Problem was that our code which checks if URI ends with file extension was > not considering that URI can have query parameters. Fixed by checking URI > path, instead of actual URI. > - Also, creation of HLS Connection holder was missing checking for mimetype, > since we do support URI without extensions as long as they provide correct > mimetype. > - Added #EXTM3U to file signature check in case if extension and mimetype > checks failed to determine stream type. All playlists of HLS based on spec > should start with #EXTM3U. For some reason this particular stream has > mimetype of "audio/x-mpegurl" and it is not mimetype from spec. Based on spec > it should be "audio/mpegurl". Thus check for signature was added in case if > URI does not use extension and has unsupported mimetype. > > Note: audio will not work on Windows and Linux for stream provided in this > bug report due to provided example uses separate audio stream via EXT-X-MEDIA > tag and it is not supported. I filed separate issue for this. Tested on windows. lgtm. - Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/750
