On Fri Dec 15 16:56:08 2023 +0000, Esme Povirk wrote:
My thinking is that we will eventually need to implement an equivalent for `GdipGetRegionHrgn` that returns some raw data instead of an HRGN, and more importantly optimizes generally for known bounding boxes (this would include the Graphics bounding box as well as its clip region). See https://gitlab.winehq.org/wine/wine/-/merge_requests/4206 for some of my initial work on that. If we do the translation outside of gdi32, we can do it by scanline and treat the path as a set of independent line segments. We can then ignore scanlines and line segments outside of our output range. I think `create_polypolygon_region` in win32 does something similar, but sadly I don't think there's a way to pass in a value for `clip_rect` from the outside.
"I don't believe draw_poly is the right place for this. Either optimizations should be in gdi32, or in SOFTWARE_GdipFillPath (which we don't use now for drawing outlines because the gdi32 path is currently more efficient, but we could if that changed)."
Looking at this again, it looks like we should try to re-implement SOFTWARE_GdipFillPath to allow for drawing outlines. Maybe add a flag for whether we need to outline only and when we need to fill it?
-
David Kahurani (＠kahurani)