[5/9] gdiplus: Fix empty glyph handling.

Vincent Povirk madewokherd at gmail.com
Tue Sep 17 11:06:22 CDT 2013


>> > Typically, native GetGlyphOutlineW(hdc, ' ', GGO_BITMAP, &gm, 0, NULL, ...)
>> > returns gm.gmBlackBoxX = 1 instead of 0. Unfortunately, Wine's didn't,
>> > and existing source codes (winex11, gdiplus, gdi32) expect 0 in this
>> > case.
>>
>> I don't think the existing code for finding the mask size would have a
>> problem with gmBlackBoxX being 0. But it would be best to skip
>> updating min_x, min_y, max_x, and max_y in this case, since we don't
>> really need the mask to include the position of an empty glyph.
>> Does Wine's GGO return a non-zero value currently? That would mean a
>> regression in gdiplus drawing only empty glyphs when you fix GGO.
>
> I didn't mean that. Native GGO returns a non-zero gmBlackBoxX/Y
> value. Wine's GGO currently returns a zero gmBlackBoxX/Y value for empty
> glyph.
> I ran some tests [1] before submitting. Please read that, for details.
> [1] http://newtestbot.winehq.org/JobDetails.pl?Key=2170
>
> Skipping updating min-max variables might be a good idea, but I feel
> this is the off topic issue. The patch intends to avoid regressions
> after fixing GGO. In other words, the aim is creating the same mask
> before and after the commit.

The loop isn't going to have a problem with 1 either. As long as the
calculated mask size includes the whole area where glyphs will need to
be drawn, there won't be a problem. Adding some extra pixels to it
isn't going to do anything take a little bit of extra time.

The logic you're adding still potentially makes the mask larger than
necessary, and it doesn't appear to do this better than the existing
logic in any meaningful way. And since the correct solution would
remove the new code entirely, I don't see the point of adding it.



More information about the wine-devel mailing list