[Bug 21534] TF2 stops when pushing on the key : "Display multiplayer scores" (tab key by default)

wine-bugs at winehq.org wine-bugs at winehq.org
Sat Apr 24 14:05:18 CDT 2010


http://bugs.winehq.org/show_bug.cgi?id=21534





--- Comment #42 from Erich Hoover <ehoover at mines.edu>  2010-04-24 14:05:17 ---
(In reply to comment #41)
> (In reply to comment #40)
> > Did you try changing the text metrics routine to rail at 127 and see if that
> > fixes it?  (Note: I don't have TF2, I just saw this on the news queue and have
> > some experience with font bugs)
> 
> Reading through the discussion of Bug 7698 (which is either the same issue or
> closely related) I decided not to push further ahead.
> I would find it a waste of my time if the most likely outcome is to maintain a
> seperate patch against either WINE or FreeType.
> This is my only use-case for WINE and as such I'm perfectly happy with simply
> modifying ClientScheme.res once.

The key here is that you have evidence of both of the following:
1) A routine returning a value greater than it should under the circumstances.
2) Wine returning a different value for the same inputs than seen on Windows.

It looks to me like that other bug only has #2 going for it, and they've thrown
in a horrible hack to fix it.  I would imagine that this bug is one of two
problems:
1) It has to do with differences in how rounding is approached in the scaling
operation, in which case it is almost certainly related to the other bug.
2) It has to do with how an "invalid" condition is handled, in which case it is
less likely to be related to the other bug (though that may just be because
they have collected less useful information than you have).

My bet would be on option #2, it appears to me that it is likely that perfectly
legitimate rounding causes the value to be too large for the glyph storage.  I
would guess that Windows rails to the maximum allowable value (since an
invalidly sized glyph would cause a crash) where Wine doesn't catch the problem
and tries to happily continue along using the invalid glyph height.  I know for
a fact that (at least a while ago) Wine didn't catch this kind of slip-up
because an application I was debugging asked for a really large scaling factor
(due to a not exactly font-related bug in Wine) and ended up asking for glyphs
~1000 pixels tall.  Trying to track this issue down I temporarily tweaked the
glyph storage to allow me to see what was going on (at the time I did not know
the glyph size was the problem) and was not-so-pleasantly greeted with a font
that consumed my entire screen.  Personally, I would expect that should you ask
for an unreasonable scaling that the closest reasonable value be substituted
instead.

So, if you find that railing the value to 127 fixes the bug for you then you
could relatively easily test for values that won't fit in a reasonable glyph
buffer.  With such a test you can rail "invalid" requests to the appropriate
size for whatever the application requested when they created the font.  Then
with that kind of patch instead of a hack, and something similar to the above
logic, you can easily justify why your patch is necessary.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the wine-bugs mailing list