Created attachment 12363 [details]
screenshot of corruption

Mailing list:

http://lists.freedesktop.org/archives/xorg/2007-October/029836.html

No follow up.

Seems driver independant as breaks with nv driver as wll

*** Bug 13212 has been marked as a duplicate of this bug. ***

Does this also happen with xserver 1.4? If not, can you try and isolate the change that introduced it with git-bisect?

i'm seeing this on i845G, but only with XAA - EXA works fine (in this regard, heh).

It doesn't happen with 1.4. I posted this first on 31.10., happened a few days before. I'll try to isolate it further when I find time for it.

Possible Temporary solution:

Option  "XAANoOffscreenPixmaps"

may fix it (see thread)

http://lists.freedesktop.org/archives/xorg/2007-December/031113.html

nope ...

Can everybody confirm that this only happens with XAA?

Fixes the issue for me:

nv driver

xserver: origin/mpx 20ace6321ac464d821c67a82c7023f74ae038176

Reported too early. It partially fixed the problem. Email now displays correctly but a pop up menu still is broken.

*** Bug 14382 has been marked as a duplicate of this bug. ***

I can reproduce this problem with the radeonhd and mga drivers, I don't see it with intel (945GM) and ati (9200).

(In reply to comment #13)
> I can reproduce this problem with the radeonhd and mga drivers, I don't see it
> with intel (945GM) and ati (9200).

Have you tried XAA vs. EXA with all drivers (where applicable)?

Looks like an XAA problem --

Option "AccelMethod" "EXA" fixes it on radeonhd and mga
EXA is the default for Intel, and the current Intel driver doesn't work at all with XAA.

Can't check ati at the moment (that box is at home)

I've just read parts of a diff between 1.4 (working) and current git (broken) - there don't seem to be any relevant changes in xaa code itself (hw/xfree86/xaa), making it likely that xaa just triggers a problem elsewhere

Yeah, most likely the glyphs-as-pixmaps changes didn't account for all the quirks of XAA.

After some more examination, the problem isn't caused by bitmap fonts, it's caused by antialiasing being off (which is always triggered by bitmap fonts, given they can't be antialiased).

Put this into fonts.conf to reproduce with TTF and Type1 fonts:

 <match target="font">
  <test name="pixelsize" compare="less">
   <double>100</double>
  </test>
  <edit name="antialias" mode="assign">
   <bool>false</bool>
  </edit>
 </match>

Are non-antialiased TTF fonts hit by the suspected glyphs-as-pixmaps changes?

I'm seeing this to an a variety of machines. Can we please, pretty pretty please have someone take a serious look at this. I'm a skilled coder and I'm willing todo any test builds necessary, we _really_ need to get this fixed!

Just to confirm that Option "AccelMethod" "EXA" fixes this font corruption on my 64 bit Gentoo system using latest git builds from this morning. Without that I was seeing widespread font corruption on anything that was not antialiased (I think). Glad there is a workaround but this is a horrible bug.

I would be willing to test any possible fixes too. This is using the r300 radeon driver (latest git build too).

Broke with a2af34d5a861982a03afad8e586bb0181b72bbd0 "Use per-screen Pixmaps for glyphs"

AFAICT this is because glyph pictures get created in card memory, and then hit an XAA fast path that assumed glyph contents were always in host memory.  Fortunately we can catch the creation of glyph pictures and force them to never get created in card memory.

Commit 718652eaf9221e0eeec2c971dd7baa97f827451b should address this.  I think.

Sadly not (in the nv driver case, at least)

Still broken on r200 and r300 too

Ah, sure.  Not only were we assuming that the bits were in host memory, we were assuming that they were stored after the GlyphRec header itself.  This is, uh... no longer the case.

Fixed in f17ba5d5849c92603f453195aca384844ca76d74 by ripping out the broken fast path.

If anyone ever wants to fix it better (and I strongly discourage making XAA any better at this point): the bits and pitch variables in the removed code need to be updated to pull their values from the glyph picture.  That's probably not all that was wrong with the code, but it was certainly some of it.

Both patches cherry-picked to server-1.5-branch, closing.

Ajax, any chance we will see this fix in F-9 proper, or as a 0 day update?

uhm, now, i can confirm that the previous corruption is gone.

instead, glyphs are now truncated vertically - usually, the part around the base line and down is missing. this seems to be a per-invocation phenomenon, as the same truncation happens within a single text fragment, but differs more or less for other ones. happens equally with exa and xaa, though, so might well be something unrelated i sucked in with the last pull. will investigate later if nobody else pins it down.

(In reply to comment #29)
> uhm, now, i can confirm that the previous corruption is gone.
> 
> instead, glyphs are now truncated vertically - usually, the part around the
> base line and down is missing. this seems to be a per-invocation phenomenon, as
> the same truncation happens within a single text fragment, but differs more or
> less for other ones. happens equally with exa and xaa, though, so might well be
> something unrelated i sucked in with the last pull. will investigate later if
> nobody else pins it down.

My test was using the fonts tab of gnome-appearance-properties, and switching between aliased and anything else.  I don't see vertical truncation there, so it's pretty likely you're seeing something different.

yes, somehow the problem resolved itself. maybe it needed a hard reboot after the driver upgrade or something.