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

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Jeffrey Smith (＠whydoubt) March 5, 2024

March 5, 2024

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) March 5, 2024

March 5, 2024

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) March 5, 2024

March 5, 2024

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) March 5, 2024

March 5, 2024

> 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) March 5, 2024

March 5, 2024

> 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) March 5, 2024

March 5, 2024

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

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) March 5, 2024

March 5, 2024

> 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_63579

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) March 5, 2024

March 5, 2024

Zebediah Figura (@zfigura) commented about dlls/d3drm/tests/d3drm.c: > + todo_wine ok(hr == D3DRM_OK, "Cannot force update of viewport, hr %#lx.\n", hr); > + hr = IDirect3DRMDevice_AddUpdateCallback(device1, update_cb_modify_rect, NULL); > + todo_wine ok(hr == D3DRM_OK, "Cannot add update callback, hr %#lx.\n", hr); > + hr = IDirect3DRMDevice_AddUpdateCallback(device1, update_cb_get_rect, &ctx); > + todo_wine ok(hr == D3DRM_OK, "Cannot add update callback, hr %#lx.\n", hr); > + hr = IDirect3DRMDevice_Update(device1); > + ok(hr == D3DRM_OK, "Cannot update Direct3DRMDevice, hr %#lx.\n", hr); > + hr = IDirect3DRMDevice_DeleteUpdateCallback(device1, update_cb_modify_rect, NULL); > + todo_wine ok(hr == D3DRM_OK, "Cannot delete update callback, hr %#lx.\n", hr); > + hr = IDirect3DRMDevice_DeleteUpdateCallback(device1, update_cb_get_rect, &ctx); > + todo_wine ok(hr == D3DRM_OK, "Cannot delete update callback, hr %#lx.\n", hr); > + todo_wine ok(ctx.rect_count == 1, "Got unexpected rect count %d, expected 1.\n", ctx.rect_count); > + todo_wine > + ok(ctx.rect.x1 == 999999 && ctx.rect.y1 <= vrect.top && > + ctx.rect.x2 >= vrect.right && ctx.rect.y2 >= vrect.bottom, > + "Got unexpected rect %s.\n", wine_dbgstr_rect((RECT *)&ctx.rect)); Any reason not to test the exact values? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63578

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) March 5, 2024

March 5, 2024

Zebediah Figura (@zfigura) commented about dlls/d3drm/device.c: > + RECT rt_rect = { 0, 0, device->width, device->height }; > + RECT ps_rect = rt_rect; > + > + ClientToScreen(device->window, (POINT *)&ps_rect.left); > + ClientToScreen(device->window, (POINT *)&ps_rect.right); > + > + TRACE("primary surface rect %s, render target rect %s\n", > + wine_dbgstr_rect(&ps_rect), wine_dbgstr_rect(&rt_rect)); > + > + hr = IDirectDrawSurface_Blt(device->primary_surface, &ps_rect, > + device->render_target, &rt_rect, DDBLT_WAIT, NULL); > + } > + > + device->needs_update = FALSE; > + } > + Can there be multiple updates? You mention the possibility of "at least" one update in your tests; should we be storing an array instead? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63577

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) March 5, 2024

March 5, 2024

Zebediah Figura (@zfigura) commented about dlls/d3drm/device.c: > device->width = desc.dwWidth; > device->height = desc.dwHeight; > > + device->needs_update = FALSE; > + The device is zero-initialized, so I don't think this hunk is necessary. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63576

1 0