March 2024 - Wine-gitlab - list.winehq.org

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

On Tue Mar 5 20:50:52 2024 +0000, Jeffrey Smith wrote: > As the documentation states that the updated region _may_ be larger than > the specified region, this seemed safer. Yeah, but I don't really want to trust that programs are following the letter of the documentation either, especially with an API this old. I'd rather at least test exact values, even if we have to mark them todo. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63598

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Jeffrey Smith (＠whydoubt) 05 Mar '24

05 Mar '24

On Tue Mar 5 19:10:38 2024 +0000, Zebediah Figura wrote: > Any reason not to test the exact values? As the documentation states that the updated region _may_ be larger than the specified region, this seemed safer. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63597

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Jeffrey Smith (＠whydoubt) 05 Mar '24

05 Mar '24

On Tue Mar 5 19:10:37 2024 +0000, Zebediah Figura wrote: > Can there be multiple updates? You mention the possibility of "at least" > one update in your tests; should we be storing an array instead? Multiple calls to ForceUpdate seem entirely reasonable. This was part of trying to keep things simple for the implementation and effectively have a single dirty-rectange. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63596

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Jeffrey Smith (＠whydoubt) 05 Mar '24

05 Mar '24

On Tue Mar 5 19:10:31 2024 +0000, Zebediah Figura wrote: > Where do these fail? - The first fails on the testbot (XP/2003) with result DDERR_CANTLOCKSURFACE. - The second fails on a local box on Win10 (with a native d3drm.dll copied in) - the color returned from get_surface_color is always 0x00ff00ff. FWIW, the `test_update_surfaces*` tests _do_ run properly on a local box of mine, running XP bare-metal. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63595

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Jeffrey Smith (＠whydoubt) 05 Mar '24

05 Mar '24

On Tue Mar 5 19:10:30 2024 +0000, Zebediah Figura wrote: > Not a big deal, but in the future I'd like to avoid this, and just > always check the actual hr value. Oops, that must've been left over from a copy-paste. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63594

1 0

Re: [PATCH v2 0/4] MR690: Release 1.11. - approved
by Alexandre Julliard (＠julliard) 05 Mar '24

05 Mar '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/690

1 0

[PATCH v3 0/10] MR5177: winewayland.drv: part 13.1: Basic OpenGL support
by Alexandros Frantzis (＠afrantzis) 05 Mar '24

05 Mar '24

This MR introduces support for OpenGL in the Wayland driver. Since the MR started to become somewhat long I have left some things for a subsequent part 13.2: * wgl(Get)SwapIntervalEXT (which means everything is vsync-ed at the moment) * wglShareLists * wglCreateContextAttribsARB * Fix for some apps appearing translucent in certain compositors (typically when fullscreen). Missing features not planned to be part of the 13.x MRs: * Offscreen rendering through pbuffers or pixmaps, since Wayland EGL doesn't support them (perhaps we can simulate with FBOs instead?). * Front buffer rendering. Again Wayland EGL doesn't support this, and certainly not in the form needed (i.e., the surface should be available for additional rendering with GDI). In the experimental branch I implemented a workaround that seemed to work for many cases, but will need to revisit and reevaluate options. IIRC, the most common case I have seen for this is when using wined3d/gl for older (Direct)2D games, so perhaps we can find a better solution at that layer. * Child window rendering (this needs infrastructure in Wayland driver core which will enable both GL and Vulkan rendering in child windows). * Cross-process rendering. Thanks! -- v3: winewayland.drv: Handle resizing of OpenGL content. winewayland.drv: Implement wglSwapBuffers. winewayland.drv: Implement wglMakeCurrent and wglMakeContextCurrentARB. winewayland.drv: Implement OpenGL context creation. winewayland.drv: Implement wglSetPixelFormat(WINE). winewayland.drv: Implement wglDescribePixelFormat. winewayland.drv: Implement wglGetProcAddress. winewayland.drv: Implement wglGetExtensionsString{ARB,EXT}. winewayland.drv: Initialize core GL functions. winewayland.drv: Add skeleton OpenGL driver. https://gitlab.winehq.org/wine/wine/-/merge_requests/5177

3 22

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

> 1. Check how multiple ForceUpdate / Clear calls influence the returned list of rectangles > 2. Check which d3drmdevice interface is passed to the update callbacks I would kind of rather check both of these things. I don't want to go in the wrong direction with the implementation. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63582

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

> Documentation for `ForceUpdate` states that "The system might update any region that is larger than the specified rectangle, including possibly the entire window". While native seems to use a sort of dirty-rectangle approach, for this MR, I am simply dirtying the entire surface. If someday someone did want to more-closely match the behavior of native, much can be learned from the rectangles passed to the update callbacks. Yeah, I can't say I'm thrilled about this. It doesn't seem like it should be that hard to implement more granular rects, at least for the cases covered here, and assuming that rects are indeed granular. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63581

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

On Tue Mar 5 19:10:33 2024 +0000, Zebediah Figura wrote: > It'd be nice to rename these parameters to left/right/top/bottom. Eh, I guess D3DRECT fields are called this. Still, I find the clearer names mildly preferable wherever possible. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63580

1 0