On Wed Apr 19 09:30:43 2023 +0000, Piotr Caban wrote:
This is temporary, it's needed so e.g. following code can work while we still use wine_get_gdi_driver:
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:
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:
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.
Ok, if it's temporary that's of course fine.
I was hoping we could eliminate the `GetTextMetrics()` / `GetTextExtentPointW()` calls at some point, since we always have the offset array in the EMF and we could likely do something on the gdi side to deal with the vertical case.