Select Git revision
Search by author
- Any Author
- authors
-
Administrator root
-
Alaric Senat
asenat
-
Alexandre Janniaux alexandre-janniaux
-
Bart - The Review Bot
Bart
-
Benjamin Arnaud
bunjee
-
Christophe Massiot cmassiot
-
Claudio Cambra
claucambra
-
David dfuhrmann
-
Denis Charmet
typx
-
Fatih Uzunoğlu fuzun
-
Felix Paul Kühne
fkuehne
-
François Cartegnie
fcartegnie
-
Gabriel Lafond-Thenaille gabriel_lt
-
**** project_435_bot_867220ea9cbb40f38051abad33491375
-
**** project_435_bot
-
Ilkka Ollakka
ileoo
-
Jean-Baptiste Kempf
jbk
-
Johannes Kauffmann
JohannesKauffmann
-
Konstantin Pavlov
thresh
-
Martin Storsjö mstorsjo
- 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>
-
- Jan 31, 2025
-
-
-
If the p_extra is freed in the previous branch, it is also freed in this branch without being reset to NULL before. Regression from a95213e2.
-
Whenever an ES selection is forced, the algorithm taking care of default selecting the tracks at ES creation should take it into account. Otherwise, tracks with highest priority will always be selected when created after an user selected one. This happens a lot in DVDs since PS sets track priority. Fixes #24815
-
-
GL_EXT_YUV_target[^1] provides a way to access an external texture without applying a conversion to RGBA texture, which can be used to supply our own matrices for conversion. This can be used to workaround bogus RGBA conversion for some devices and can help integrating better with deinterlacing, or in general plane filtering, and some YUV pipeline like encoding. [^1]: https://registry.khronos.org/OpenGL/extensions/EXT/EXT_YUV_target.txt
-
-
When a filter could not load because of a sampler creation failure, there were no messages indicating that it came from the sampler, nor information on what failed in the sampler.
-
-
-
A new YUV list is created to avoid adding the new chroma to YUV fallbacks.
-
