On Fri Dec 15 16:05:24 2023 +0000, David Kahurani wrote:
> I guess the way forward would be:
> 1) Optimize `GdipGetRegionHrgn` in GDI+ which is done in this
> MR(assuming we remove the last patch)
> 2) Optimize `DrawPoly` in gdi32
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.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3288#note_56116
Stopping my detailed review because I don't think this approach to optimizing the path is quite right.
Suppose I fill a polygon that very closely approximates a circle, that this circle contains the entire bounding rectangle of the Graphics object, and that it does not intersect any edges of the bounding rectangle. That would mean that none of the individual points intersect the bounding rectangle. For a sufficiently close approximation, no set of 3 adjacent points in the polygon would intersect the bounding rectangle.
If I understand correctly how `clip_path` is meant to work, it would remove every point except for the starting point, which would mean that nothing would be drawn, when instead the full bounding box of the Graphics object should be filled.
I think that in order to fix this case, you would need to ignore any points not added to the output rectangle. So if I have a polygon that goes A B C D (with A being a start point and B C D being line points), and point B is removed, then you need to check points A, C, and D in order to determine whether point C can be removed.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3288#note_56114
DMUS_PMSG::dwType is the type of the message, but we are comparing it to
curve types. We should be using DMUS_CURVE_PMSG::bType instead.
* * *
(I tried to write some test cases for this. I created a IDirectMusicPort implementation that checks the generated midi commands, but instead I cannot get Windows to generate any midi commands for CCCURVEs. )
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4703
Validate user data before passing it to PolyDraw.
The program in the bug requests to draw figures outrageously outside the DC's region after presumably, some uninitialized values happen as a result of a missing font. Native gdiplus seems to handle this gracefully so we probably also should.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=41617
Signed-off-by: David Kahurani <k.kahurani(a)gmail.com>
--
v7: gdiplus: Hook on optimized path drawing code
gdiplus: Re-implement trace_path to avoid circular dependency
gdiplus: Make get_region_hrgn public to gdiplus
gdiplus: Clip polygons before drawing them
gdiplus: Make get_graphis_device_bounds public to gdiplus
gdiplus: Allow for writing nodes to an empty path points list
https://gitlab.winehq.org/wine/wine/-/merge_requests/3288