- May 03, 2019
-
-
In Qt, on capability changes, a signal was emitted for all capabilities regardless of whether they actually changed. Instead, only emit a signal for capabilities which changed. Signed-off-by:
Thomas Guillem <thomas@gllm.fr>
-
The capabilities are stored in a bitset. When it changes, it may be useful to know its old value, to know which capability changed. Signed-off-by:
Thomas Guillem <thomas@gllm.fr>
-
There were helpers for retrieving the selected title, chapter or track, but a helper for the selected program was missing. Signed-off-by:
Thomas Guillem <thomas@gllm.fr>
-
A title list can be held, so vlc_player_GetTitleList() returns a pointer to a non-const title list. Signed-off-by:
Thomas Guillem <thomas@gllm.fr>
-
Signed-off-by:
Steve Lhomme <robux4@ycbcr.xyz>
-
- May 02, 2019
-
-
Martin Storsjö authored
As fxc2 relies on a precompiled binary for x86, which we need to run at build time, we need to look for an x86 cross compiler, in case the current target for contribs isn't x86. Remove the patch for adding a meson build system to fxc2. fxc2 consists of one single source file, and when building with meson, one must create a cross file in order to specify using a different cross compiler, just passing the name as a parameter isn't possible. Therefore, just resort to manually compiling the single file, instead of adding a new buildsystem that upstream doesn't contain and which makes cross compiling with arbitrary compilers harder.
-
Felix Paul Kühne authored
-
Felix Paul Kühne authored
-
Felix Paul Kühne authored
-
Felix Paul Kühne authored
This also fixes the indent on top and bottom for the collection view.
-
François Cartegnie authored
-
Steve Lhomme authored
Rather than the windows ARRAYSIZE() which ends up as sizeof(*RtlpNumberOf(A)) mostly for C++.
-
- Apr 30, 2019
-
-
François Cartegnie authored
-
François Cartegnie authored
-
Steve Lhomme authored
-
Steve Lhomme authored
-
Steve Lhomme authored
In external rendering these fields should never be used.
-
François Cartegnie authored
-
François Cartegnie authored
refs broken #22228
-
François Cartegnie authored
-
François Cartegnie authored
-
François Cartegnie authored
-
François Cartegnie authored
-
François Cartegnie authored
that really can't work due to empty segments and be fixed without big changes
-
François Cartegnie authored
pretty useless since we can no longer change it...
-
François Cartegnie authored
-
François Cartegnie authored
-
Steve Lhomme authored
In that case we don't call CommonInit. We also check that on Winstore the legacy "winrt-d3dcontext" variable is set if an external callback is not used.
-
Steve Lhomme authored
During fast resizing we might get a lot of WM_SIZE messages which are each sending a CHANGE_DISPLAY_SIZE which may take time to get to the display thread. We bypass a part of this lag by reading directly the current size of our parent HWND (since we always place our HWND at 0,0 with the full size). This is similar to what we have before when we handled all the HWND in this part of the code. We read the window size directly on each size change.
-
Steve Lhomme authored
The dimension to use is always set in area->vdcfg.display. The hwnd size always matches this size since we resize it accordingly for each DISPLAY_CHANGE_DISPLAY_SIZE call. There is a slight delay between the moment the window tells the core of the size change and the moment it's effective in the display. So resizing quickly is not as smooth as when reading the HWND size directly.
-
Steve Lhomme authored
Implement the TODO: call a DISPLAY_CHANGE_DISPLAY_SIZE when we detect the external swapchain dimensions have changed. We don't need a special callback to read the "display" dimensions.
-
Steve Lhomme authored
At some point this code should go away.
-
Steve Lhomme authored
area->vdcfg is always set to the display size received from the core.
-
Steve Lhomme authored
When rendering to NV12/P010 otherwise we only need one.
-
Steve Lhomme authored
We don't need to know anything about the display module in Common code. Only the Init needs to keep track of the source video format.
-
Steve Lhomme authored
So we don't have to pass the display module at each UpdateRects nor the source video_format_t. It may also change if the texture is bigger than the decoded size (D3D11 extra padding).
-
Steve Lhomme authored
They always cover the same (window) area so there's no reason to use two. We do not need to know the first placement of the video window. It's always shown (black) from the start now.
-
Steve Lhomme authored
It is always true now that all modules have been fixed to properly place the textures.
-
Steve Lhomme authored
-
Steve Lhomme authored
-