Allowing the job to fail to avoid failing the pipeline. Some new tests
are failing with it, and some are succeeding todo_wine.
--
v5: gitlab: Run user32 32-bit tests with nulldrv driver.
user32/tests: Update todos specific to the X11 display driver.
user32/tests: Check graphics driver and add todos for nulldrv.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1259
Implements navigation bar featuring:
- back/forward buttons
- go up button
- address crumbs
- hides crumbs when there's not enough space to display all of them
- always shows at least 2 crumbs
- truncating them if needed
- first crumb is at least 56px
- aligns label to the left if truncated
- right clicking on the crumb, or free space, opens a menu with `Copy address as text` and `Edit address` options
- reuses existing crumbs to avoid some flickering
- overflow menu
- ~~first crumb is always moved here~~
- removes the split, if there are no items in the menu
- hidden crumbs are moved here
- left ~~or right~~ click on the button starts address editing
- address edit
- accepts an existing path
- expands environment variables, e.g. `%APPDATA%\Microsoft` -> `C:\users\%USERNAME%\AppData\Roaming\Microsoft`
- errors with a `MessageBox` on nonexistent paths
- refresh button
- changes into go to button when editing address
- DPI scaling
Screenshots:
![navbar-crumbs-classic](/uploads/8c9a806b57f8e456fcbfd3cbc1ef3bb7/navbar-crumbs-classic.png)
![navbar-crumbs-light](/uploads/9c8a7acf9b55ae5ac182219edd45b65d/navbar-crumbs-light.png)
![navbar-edit-classic](/uploads/f68309bbc9200a8d8d4e3cd692179409/navbar-edit-classic.png)
![navbar-edit-light](/uploads/6798e79e6d2498a052b0ecbc2545c6e4/navbar-edit-light.png)
![navbar-120dpi-classic](/uploads/72abee382ab6171ff9c1b99a9065c845/navbar-120dpi-classic.png)
![navbar-120dpi-light](/uploads/538a030bc2028f8654d6c35d6f2825dd/navbar-120dpi-light.png)
Remaining issues:
- crumbs not lighting up when hovered sometimes
- can be observed in current file dialog, hovering over dropdown arrow of a file type fixes it for a moment
- crumbs flickering on address change sometimes
- mostly when there's not enough space to display all of them
- `DeferWindowPos` doesn't seem to be atomic in Wine, presumably is in native Windows?
- unexpected address conversion for some PIDLs
- e.g. `Desktop` -> `C:\users\%USERNAME%\Desktop`, which is an entirely different location
- or `My Computer` into an empty string
- known folders are not handled by address edit, e.g. `Desktop`, `My Computer`
- icons are not DPI scaled
- while writing this:
```
0024:fixme:bitmap:NtGdiCreateBitmap planes = 0
0024:err:system:user_check_not_lock BUG: holding USER lock
wine/dlls/win32u/sysparams.c:396: user_check_not_lock: Assertion `0' failed.
wine: Assertion failed at address F7FF8549 (thread 0024), starting debugger...
```
- can't reproduce, happened when clicking on an item in overflow menu
- race condition? cosmic ray?
Addresses following bugs:
- https://bugs.winehq.org/show_bug.cgi?id=29912
- https://bugs.winehq.org/show_bug.cgi?id=50338
- https://bugs.winehq.org/show_bug.cgi?id=51855 (partially? no search box)
--
v13: comdlg32: Add Ctrl+Backspace delete word to IFileDialog address edit.
comdlg32: Use path word break in IFileDialog address edit.
comctl32: Fix PathWordBreakProc.
comdlg32: Keep IExplorerBrowser in IFileDialog focused after Backspace.
fixup: comdlg32: Add address edit to IFileDialog navigation bar.
comdlg32: Add refresh/go to button to IFileDialog navigation bar.
comdlg32: Add address edit to IFileDialog navigation bar.
comdlg32: Add breadcrumb overflow menu to IFileDialog navigation bar.
comdlg32: Add address breadcrumbs to IFileDialog navigation bar.
comdlg32: Add go up button to IFileDialog navigation bar.
comdlg32: Add IFileDialog navigation bar.
comdlg32: Enable visual styles when showing IFileDialog.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1857
--
v3: ntdll: Add return address information in __wine_debug_context.
ntdll: Add file and line information in __wine_debug_context.
ntdll: Introduce struct __wine_debug_context for extensible debug info.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2274
--
v3: d2d1/tests: Test IsSupported() for bitmap render targets.
d2d1: Implement d2d_bitmap_render_target_IsSupported().
d2d1/tests: Test IsSupported() for DC render targets.
d2d1: Implement d2d_dc_render_target_IsSupported().
d2d1/tests: Test IsSupported() for hwnd render targets.
d2d1: Implement d2d_hwnd_render_target_IsSupported().
https://gitlab.winehq.org/wine/wine/-/merge_requests/811
This improves performance for the game "Grounded", on a AMD Radeon RX 6700 XT,
with radv from Mesa 22.3.6. Testing was done with the "cb_access_map_w" option
enabled, which also improves performance with the game by itself.
From my testing, it's possible to raise the threshold from 2 ms up to 5 ms or
so, before the driver or GPU seems to reclock back to the lower power level.
However, this measurement is questionable for several reasons. It seems to vary
depending on the scene being rendered, and of course this will be specific to
the game and driver and GPU in question anyway. The game also has a weird
approach to vsync that seems to involve it presenting stale frames (and hence
artificially inflating the FPS), which I'm not fully sure I accounted for while
measuring. And of course, it's hard to be sure that 5 ms is actually the
threshold for how long the driver will go before powering down the GPU. In any
case, it seems better to err on the side of submitting more often, to make sure
the fix affects more drivers.
While submission isn't cheap, it seems to me that submitting every 2 ms is
unlikely to cause a bottleneck [consider that this is at most 8 (more)
submissions per frame].
The maximum of 4 concurrent periodically submitted buffers was chosen
arbitrarily. Removing the maximum altogether does not measurably affect
performance for this game either way.
Credit goes to Philip Rebohle and his work on DXVK for helping me to notice that
periodic submission might make a difference.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2724
Rationale:
- currently, winetest is built either as a 32bit exec or a 64bit exec,
containaing a bunch of tests of same bitness.
- there's no simple support for having parent process in one bitness,
and child process in a different bitness.
- lots of cases are not covered in ntdll, kernel32 and kernelbase tests.
- there are here and there a couple of tweaks to workaround this,
but nothing a bit solid.
Attached is a proposal to extend winetest to support better these
use cases:
- the idea is to add an extra-option to winetest.exe (64bit)
passing the path to the corresponding winetest.exe (32bit).
- when running test X (64bit), the path to corresponding test X (32bit)
will be passed to test X (64 bit), allowing it to trigger test
with test X (32bit).
- nothing more is provided: it's up to the test designer to decide
whether to use the 32bit child (and to adapt potentially the test)
to cope with the difference in bitness between parent and child.
- this can be used either in current wow64 setup, and also in
multi-arch wow64 setup (just need to change the patch to 32bit
winetest.exe)
There's an example of such test at the end of the serie.
Comments, ideas welcomed. And especially if it's something worth
continuing.
Note:
- this is first shot at it, it should be improved (especially in
ensuring that the 32bit/64bit pair is correct).
A+
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2002