The D3D12 swapchain code is currently quite messy, probably because it was originally designed around the direct usage of the Vulkan swapchain images, then the support for user buffers was added, and the original design was later phased out. Currently the internal state can be divided in two different sets of objects: the "D3D12 side", which is visible to the `IDXGISwapChain` client and must be preserved at all times (except on the client's request, i.e., when `UpdateBuffers()` is called) and the "Vulkan side" which is private and can be destroyed and recreated more or less transparently (in case the Vulkan swapchain goes out of date or some settings are updated).
This MR begins the process of de-intertwining the helpers that act on one or the other sides, so that the structure of the code is made clearer. The full patch set is at https://gitlab.winehq.org/giomasce/wine/-/commits/chianti.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2930
This is to prevent NULL pointers when creating a TextService with no rows in it.
This NULL pointers doesn't happen when creating a richedit windows, because
it sets an empty text when the richedit window procedure handles the WM_CREATE event.
--
v4: riched20: Call ME_UpdateRepaint instead of editor_ensure_visible in set_selection.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2941
This is to prevent NULL pointers when creating a standalone text service
that doesn't have any text set and then using functions like EM_SETSEL.
This NULL pointers doesn't happen when creating a richedit windows, because
it sets an empty text when the richedit window procedure handles the WM_CREATE event.
--
v3: riched20: Check if row is null in editor_ensure_visible.
riched20: Return NULL if no row is found in row_from_cursor.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2941
On Fri Jun 2 17:22:54 2023 +0000, Huw Davies wrote:
> Could you split this MR into two or three smaller ones? - just force
> push the first few commits to this one, then, once this is merged, send
> the next one.
Done.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2934#note_34477
The goal of this MR is to set up the minimum necessary infrastructure to display the contents of some simple, software rendered windows. This involves two major steps:
1. Associate a window with a Wayland surface and give it the `xdg_toplevel` role, so that the compositor can display it. We also have to implement the required initial `xdg_surface` configuration sequence to be able to safely (i.e., without the compositor disconnecting us with an error) attach buffers to the surface in step (2).
2. Implement the `window_surface` interface for the Wayland driver. For now we provide a simple (and suboptimal) `window_surface_flush` implementation: for each flush we create a new `wl_shm` buffer, copy the whole window contents (ignoring damaged bounds for now) into it and attach it to the target Wayland surface. In the next MR I will optimize this implementation in multiple ways: a. implement a buffer queue to avoid constantly allocating new buffers b. respect the damaged bounds of the `window_surface` to minimize copying of data from the `window_surface` to the SHM buffer (and also for correctness) c. communicate damaged surface regions to the compositor to (potentially) allow more efficient texture uploads.
With this MR many (software-rendered) applications can now display dynamic content on screen. We can't interact with the apps yet, but we do get to enjoy `notepad` in all its blinking-cursor glory.
Thanks!
--
v2: winewayland.drv: Implement a simple window_surface flush.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2944