This part introduces support for Vulkan swapchains to the Wayland driver:
* Implement several Vulkan functions typically called to get info before swapchain creation.
* Implement swapchain creation/destruction
* Implement getting swapchain images.
I stopped short of adding presentation support since the MR would grow too big (stay tuned for part 10.3).
Thanks!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4456
This program is in GUI subsystem, but expects I/O
with Unix console. This is a Wine specific behavior.
So explicitely use unix fd instead of the inherited
standard handles.
Wine-Bugs: https://bugs.winehq.org/show_bug.cgi?id=55723
Signed-off-by: Eric Pouech <epouech(a)codeweavers.com>
--
v2: regedit: Use message boxes by default for output.
regsvr32: Use message boxes by default for output.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4440
Freetype's FT_Load_Glyph may return different glyph metrics (in particular, horiAdvance) depending on load target flags (FT_LOAD_TARGET_MONO, FT_LOAD_TARGET_NORMAL ...). Among the consequences of that are:
- the size of, e. g, GetTextExtentPoint() doesn't match the size of actually rendered text;
- DrawTextW() with DT_CALCRECT flag returns wrong bounding rectangle.
In the core of that is GetGlyphOutline() returning different values for GGO_METRICS format (used in various glyph metrics query functions) and the actual format used during rendering.
It probably make sense to use effective fonts rendering option for GGO_METRICS so that matches. I did some ad-hoc testing on Windows with currently problematic Tahoma font and quite expectedly GetGlyphOutline(GGO_METRICS) always returns the same metrics as other output format options. While all the options also have the same metrics between each other (which is still not the case with Wine). I guess it is not easily possible to make all the face load options match each other with freetype (nor I am sure that is always the case on Windows for all the possible fonts), but making GGO_METRICS return the metrics matching actual gdi device context setup looks more important.
Fixes Idle Spiral being unable to render typed text in save / load dialogs (which is using Winforms from Unity's Mono).
--
v2: win32u: Use font AA flags when querying glyph outline with GGO_METRICS.
d3dx9/tests: Make test_ID3DXFont() less dependent on GetGlyphOutlineW(GGO_METRICS) behaviour.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4406
It looks like msvcp doesn't export anything for the std::bad_function_call exception construction and if std::bad_function_call is constructed directly from the app the corresponding class data is generated in the application binary.
I am attaching an ad-hoc test program I used to test it (using MSVC 2022 community edition).
[msvcp_except.cpp](/uploads/558f0911366525d05af4ac69552c4aae/msvcp_except.cpp)
--
v2: msvcp110: Implement std::_Xbad_function_call().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4446
On Tue Nov 21 15:10:16 2023 +0000, Rémi Bernon wrote:
> I suspect this is actually related to the tests using WMAUDIO2 (aka
> WMAudioV8), which, if I believe the headers files, where
> WMAUDIO_BITS_PER_SAMPLE is used, only supports 16bps. The bps is then
> automatically set and the media type doesn't need one.
> Also from the headers, I suspect WMAUDIO3 may support variable bps which
> maybe would require changes here and in other places where we use a
> fixed value. All of which may require more tests to be sure. Which
> probably could be added later.
Yes, more tests always help. But GStreamer/ffmpeg don't have any WMA3/WMALossless/WMV3/WMVA/WVC1 encoders, and Windows' media APIs are _complicated_, so I couldn't produce any suitable test files.
Probably not a huge deal which output format we use, we've got audioconvert elements. But there's also no point hardcoding things when there's a depth field in struct wg_format; fixed.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4450#note_53102