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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4206#note_63271