On Wed Apr 19 08:23:37 2023 +0000, Huw Davies wrote:
What's the plan with this - how does this work when we switch the driver interface to the unix-side?
This is temporary, it's needed so e.g. following code can work while we still use wine_get_gdi_driver: ```c dev = GET_NEXT_PHYSDEV( dev, pGetTextMetrics ); return dev->funcs->pGetTextMetrics( dev, metrics ); ``` After `wine_get_gdi_driver` path is removed, the code will be changed to: ```c return GetTextMetricsW(dev->hdc, metrics); ``` (and `font_GetTextMetrics` will be removed, note that dev->hdc points to memory DC in this case).
The alternative is to change the callers to something like: ```c if (dev.next) //we can mark what path is used in PSDRV_DEVICE to make it more explicit { dev = GET_NEXT_PHYSDEV( dev, pGetTextMetrics ); return dev->funcs->pGetTextMetrics( dev, metrics ); } else { return GetTextMetricsW(dev->hdc, metrics); } ``` I'm not sure if it answers your question. I was thinking that the plan is to implement small parts of user-mode DDI so the driver interface is not on the unix side. I was already doing some tests regarding how it's done for GetDeviceCaps call (and it's basically a matter of copying the caps to structure supplied by GDI). I guess it will be harder for device font related functions. If we end with some other solution this part may need to be changed.