On Mon Feb 26 20:46:41 2024 +0000, Esme Povirk wrote:
It occurred to me in discussing https://gitlab.winehq.org/wine/wine/-/merge_requests/5152 that we could take advantage of gdi32's clipping optimization by drawing to a DIB, and using the DIB as a representation of which pixels are in a region. But we'd have to specifically use `PolyPolygon` to do the drawing. (Or, maybe it'd be better to update other gdi32 drawing functions so they can use the optimization, and we can keep using `draw_poly`?) Also, I tried doing the bounding box calculation at the same time as the region conversion, and having to worry about combining regions with different bounding boxes made things way more complicated. I believe working that out separately is worth it just to keep things simpler. The plan I'm now favoring is:
- Merge this basically as-is.
- Reimplement `brush_fill_path` and `GDI32_GdipFillPath` based on
`PolyPolygon`, so that gdi32 will use the clipping optimization (this also gets us code that converts to a point list for PolyPolygon which we can reuse later).
- Write tests for exactly where the pixel boundaries are with
rectangular regions so we can make sure get_region_bounding_box is precise in that situation.
- Write a function that takes a boundary rectangle and a region, and
returns a black & white DIB representing the region's intersection with the rectangle (can skip generating the DIB in some trivial cases). We'll replace `GdipGetRegionHRgn` with that. At that point, `GdipIsVisibleRegionPoint` can skip the boundary box calculation and just use that with a 1x1 rectangle.
If we're sailing on the same boat then said gdi32 clipping optimization was not primarily an optimization.
This was primarily a bug fix and will remain as one such unless it is proven to be reasonably broken.
Which it is, but no-one noticed.