- Feb 03, 2025
-
-
Fatih Uzunoğlu authored
This reverts commit 185d3fba.
-
Fatih Uzunoğlu authored
We currently use `qmlcachegen`, but we don't need to necessarily provide that tool because Qt saves the cached QML types into files at first start-up* anyway. We do not need to care too much about the performance of the first start-up. And, this patch does not remove the functionality of using the `qmlcachegen` tool. The said tool can still be used when it is present. It should be also noted that it is beneficial to have `qmlcachegen` in a development setup, because it tells if a QML file contains some errors. After this patch, the CI is still going to use the tool in other builds. This enables reverting 185d3fba, which in turn enables us to update patch version of Qt without updating the images used by the CI that contain the tools. Exact version dependency of the tools are in fact only valid for `qmlcachegen`. Rest of the tools only demand equal or greater Qt version, and do not care if patch version is different. * In fact, the very first loading of the type.
-
Steve Lhomme authored
This will avoid errors like fbbd68f8.
-
Steve Lhomme authored
-
Steve Lhomme authored
The DMO code is enabled for non-UWP targets and all Windows targets have this DLL (since Vista). msdmo.dll with DMOEnum() is available in vanilla Windows 7. If for some reason the DLL is not there, the plugin won't be loaded and it will rightfully be skipped.
-
This fixes delegate can not be loaded issue with Qt 6.2.
-
Functioning of double clicking list view delegate is broken due to "Error: Insufficient arguments". At the same time, `currentIndex` should be used instead of the first selected item when view is requested.
-
It is not clear why such signal exists, it seems that it is supposed to be a function instead. Regardless, having such signal is not meaningful because there is already `currentIndex` which is synchronized with the shown artist. This synchronization is satisfied by the change handler. The change handler already needs to adjust the artist id (for synchronization), making `showArtist()` meaningless. Currently clicking a delegate does not change the current index. Views should change the current index when clicking on delegate.
-
It does not make sense to adjust selection within `resetFocus()`. This causes the initial selection to be the first item while normally there should not be a selection initially.
-
-
- Feb 02, 2025
-
-
Here, Qt wants to create a layer because when source is `QQuickImage`, `QGfxSourceProxy(ME)` checks its fill mode and source size. In this case, we need to tell Qt that we don't need a layer here, as we are doing the mapping as we want but Qt currently does not offer a way to tell that and simply tries to decide itself: "If needed, MultiEffect will internally generate a ShaderEffectSource as the texture source" Using the static texture for the blur source has also the advantage of applying blur only once because the source would not get updated constantly due to size change. With clipping, we can simply adjust the viewport without needing to update the blur. Unfortunately we can not do this with older Qt versions, because if the source image changes fill mode from stretch or to stretch where it is fed to a blur effect, the effect either causes crash (layering needed to not needed, so Tile -> Stretch) or does not work (layering not needed to needed, so Stretch -> Tile).
-
Steve Lhomme authored
-
- Feb 01, 2025
-
-
Switch to cmake from this commit since the previous smb2 version has not a fully functional cmake configuration.
-
-
To prepare for the next commit.
-
To avoid conflicts with smb2.h
-
Steve Lhomme authored
-
Steve Lhomme authored
Similar to ca1e1569. GetCurrentThreadStackLimits is also available in UWP.
-
-
Steve Lhomme authored
We don't need to create an object just to load the DLL shaders.
-
Steve Lhomme authored
It redirects to the d3dcompiler_47.dll in mingw-w64 and in the Windows SDK that's the only variant there is. This is also how D3DCompile() is supposed to be used [^1]. The DLL is available in Windows 7 with Platform Update [^2]. No version of d3dcompiler_XXX.dll is available in vanilla Windows 7 which doesn't have Direct3D11 anyway. [^1]: https://learn.microsoft.com/en-us/windows/win32/api/d3dcompiler/nf-d3dcompiler-d3dcompile [^2]: https://learn.microsoft.com/en-us/windows/win32/direct3darticles/platform-update-for-windows-7
-
Steve Lhomme authored
We don't use it anymore.
-
Steve Lhomme authored
This is standard Windows API calls that we can call manually.
-
The fmt passed to vlc_gl_interop_New() is const, the new changed chroma is in interop->fmt_in. This fixes crashes and assert after vd->ops->update_format() that required a chroma change. PS: if update_format() fails, a video converter will be inserted in the static filter chain.
-
Delegate images are meant to be cached, and put in the atlas. We have to use a reasonable size otherwise they can easily spoil the cache. Currently source size is used as worst case (the largest the image can be), but most of the time the interface window size is wide enough to display multiple items, where in that case item size is not as large as the worst case. Granted this will make images have poorer quality when the interface has such a size that only one/two items are visible per row, as then the items would scale up to use the all available width. However, it needs to be balanced. I propose using the average case and not the worst case for the source size. I propose that we determine the average (nbItemPerRow) to be 3 for the moment. This means that we target the optimal quality when there are at least three items displayed per row and not less. I used the formula provided in the comments, one line above.
-
-
This causes the cursor to remain busy forever.
-
Partially changing a value type changes the whole value. In image case, this means that the images can get re-loaded with indeterminate size just to discard them after the size is determined. Fortunately this does not happen currently, because the sizes are determined before the component is complete and QQuickImage only loads if the component is complete. However, due to the declarative nature of QML, bindings are evaluated and assigned one by one, this means that source size would be changed two times even if .width and .height are pending re-evaluation at the same time (such as both depend on DPR). At the same time, the order is also not defined, so with such a setup as following: sourceSize.width: width * eDPR sourceSize.height: height * eDPR When eDPR changes, Qt evaluates the binding for width or height, adjusts sourceSize, sourceSize changes and change signal is signalled, then evaluates the other sub-part of the value type (width or height), adjusts sourceSize, sourceSize changes again and change signal is signalled. Qt could technically optimize this, but as of Qt 6.8.1 it is not the case. Meanwhile with the following: sourceSize: Qt.size(width * eDPR, height * eDPR) When eDPR changes, Qt evaluates the binding and adjusts the source size, sourceSize changes and change signal is signalled. Source size does not change two times, and the image would not be loaded two times.
-
Partially changing a value type changes the whole value. In image case, this means that the images can get re-loaded with indeterminate size just to discard them after the size is determined. Fortunately this does not happen currently, because the sizes are determined before the component is complete and QQuickImage only loads if the component is complete. However, due to the declarative nature of QML, bindings are evaluated and assigned one by one, this means that source size would be changed two times even if .width and .height are pending re-evaluation at the same time (such as both depend on DPR). At the same time, the order is also not defined, so with such a setup as following: sourceSize.width: width * eDPR sourceSize.height: height * eDPR When eDPR changes, Qt evaluates the binding for width or height, adjusts sourceSize, sourceSize changes and change signal is signalled, then evaluates the other sub-part of the value type (width or height), adjusts sourceSize, sourceSize changes again and change signal is signalled. Qt could technically optimize this, but as of Qt 6.8.1 it is not the case. Meanwhile with the following: sourceSize: Qt.size(width * eDPR, height * eDPR) When eDPR changes, Qt evaluates the binding and adjusts the source size, sourceSize changes and change signal is signalled. Source size does not change two times, and the image would not be loaded two times.
-
Partially changing a value type changes the whole value. In image case, this means that the images can get re-loaded with indeterminate size just to discard them after the size is determined. Fortunately this does not happen currently, because the sizes are determined before the component is complete and QQuickImage only loads if the component is complete. However, due to the declarative nature of QML, bindings are evaluated and assigned one by one, this means that source size would be changed two times even if .width and .height are pending re-evaluation at the same time (such as both depend on DPR). At the same time, the order is also not defined, so with such a setup as following: sourceSize.width: width * eDPR sourceSize.height: height * eDPR When eDPR changes, Qt evaluates the binding for width or height, adjusts sourceSize, sourceSize changes and change signal is signalled, then evaluates the other sub-part of the value type (width or height), adjusts sourceSize, sourceSize changes again and change signal is signalled. Qt could technically optimize this, but as of Qt 6.8.1 it is not the case. Meanwhile with the following: sourceSize: Qt.size(width * eDPR, height * eDPR) When eDPR changes, Qt evaluates the binding and adjusts the source size, sourceSize changes and change signal is signalled. Source size does not change two times, and the image would not be loaded two times.
-
Partially changing a value type changes the whole value. In image case, this means that the images can get re-loaded with indeterminate size just to discard them after the size is determined. Fortunately this does not happen currently, because the sizes are determined before the component is complete and QQuickImage only loads if the component is complete. However, due to the declarative nature of QML, bindings are evaluated and assigned one by one, this means that source size would be changed two times even if .width and .height are pending re-evaluation at the same time (such as both depend on DPR). At the same time, the order is also not defined, so with such a setup as following: sourceSize.width: width * eDPR sourceSize.height: height * eDPR When eDPR changes, Qt evaluates the binding for width or height, adjusts sourceSize, sourceSize changes and change signal is signalled, then evaluates the other sub-part of the value type (width or height), adjusts sourceSize, sourceSize changes again and change signal is signalled. Qt could technically optimize this, but as of Qt 6.8.1 it is not the case. Meanwhile with the following: sourceSize: Qt.size(width * eDPR, height * eDPR) When eDPR changes, Qt evaluates the binding and adjusts the source size, sourceSize changes and change signal is signalled. Source size does not change two times, and the image would not be loaded two times.
-
Partially changing a value type changes the whole value. In image case, this means that the images can get re-loaded with indeterminate size just to discard them after the size is determined. Fortunately this does not happen currently, because the sizes are determined before the component is complete and QQuickImage only loads if the component is complete. However, due to the declarative nature of QML, bindings are evaluated and assigned one by one, this means that source size would be changed two times even if .width and .height are pending re-evaluation at the same time (such as both depend on DPR). At the same time, the order is also not defined, so with such a setup as following: sourceSize.width: width * eDPR sourceSize.height: height * eDPR When eDPR changes, Qt evaluates the binding for width or height, adjusts sourceSize, sourceSize changes and change signal is signalled, then evaluates the other sub-part of the value type (width or height), adjusts sourceSize, sourceSize changes again and change signal is signalled. Qt could technically optimize this, but as of Qt 6.8.1 it is not the case. Meanwhile with the following: sourceSize: Qt.size(width * eDPR, height * eDPR) When eDPR changes, Qt evaluates the binding and adjusts the source size, sourceSize changes and change signal is signalled. Source size does not change two times, and the image would not be loaded two times.
-
Partially changing a value type changes the whole value. In image case, this means that the images can get re-loaded with indeterminate size just to discard them after the size is determined. Fortunately this does not happen currently, because the sizes are determined before the component is complete and QQuickImage only loads if the component is complete. However, due to the declarative nature of QML, bindings are evaluated and assigned one by one, this means that source size would be changed two times even if .width and .height are pending re-evaluation at the same time (such as both depend on DPR). At the same time, the order is also not defined, so with such a setup as following: sourceSize.width: width * eDPR sourceSize.height: height * eDPR When eDPR changes, Qt evaluates the binding for width or height, adjusts sourceSize, sourceSize changes and change signal is signalled, then evaluates the other sub-part of the value type (width or height), adjusts sourceSize, sourceSize changes again and change signal is signalled. Qt could technically optimize this, but as of Qt 6.8.1 it is not the case. Meanwhile with the following: sourceSize: Qt.size(width * eDPR, height * eDPR) When eDPR changes, Qt evaluates the binding and adjusts the source size, sourceSize changes and change signal is signalled. Source size does not change two times, and the image would not be loaded two times.
-
Partially changing a value type changes the whole value. In image case, this means that the images can get re-loaded with indeterminate size just to discard them after the size is determined. Fortunately this does not happen currently, because the sizes are determined before the component is complete and QQuickImage only loads if the component is complete. However, due to the declarative nature of QML, bindings are evaluated and assigned one by one, this means that source size would be changed two times even if .width and .height are pending re-evaluation at the same time (such as both depend on DPR). At the same time, the order is also not defined, so with such a setup as following: sourceSize.width: width * eDPR sourceSize.height: height * eDPR When eDPR changes, Qt evaluates the binding for width or height, adjusts sourceSize, sourceSize changes and change signal is signalled, then evaluates the other sub-part of the value type (width or height), adjusts sourceSize, sourceSize changes again and change signal is signalled. Qt could technically optimize this, but as of Qt 6.8.1 it is not the case. Meanwhile with the following: sourceSize: Qt.size(width * eDPR, height * eDPR) When eDPR changes, Qt evaluates the binding and adjusts the source size, sourceSize changes and change signal is signalled. Source size does not change two times, and the image would not be loaded two times.
-
This fixes the layouting issue where the cone bar overlaps with the menu bar when the page changes (such as, switching to player view).
-
This setting allows disabling picture-in-picture mode.
-
This adds the clock context id metric which allows tracking some of the lipsync issues by checking every contexts are switching to the new context reliably. In this patch, clock->context can be null, but in future work it will never be NULL. This also setup a new tag on traces exposed by TraceRender to separate the metrics where ts is the current time and metrics where ts is a time provided by the tracer user. The rationale is that some systems cannot render non-monotonic metrics and the time at which the event appear is more important than the value of the timestamp, which should be traced separately.
-
This reports the buffering level (in ms) from the input clock in the traces, which is useful to analyze artifacts generated by the access or the input mainloop, as well as the startup condition.
-
This reports the buffering level (in ms) from the input clock in the es_out, so that the core can track the buffering level in the current playback. The es_out is currently only using the value if positive to trigger a rebuffering. Previous <= 0 values were discarded.
-
The events are tracing when decoders are ready for the input to start, providing details on why the playback startup is being delayed. Co-authored-by:Thomas Guillem <thomas@gllm.fr>
-
