Created attachment 374584 [details] smudgy/shadowy fonts in various apps and sizes. Description of problem: Fonts, especially small ones, look very smudgy and shadowy regardless of "System - Preferences - Appearance - Fonts" settings. The component might be wrong but I don't know which one would be the right one. Version-Release number of selected component (if applicable): xorg-x11-drv-ati-6.13.0-0.11.20091119git437113124.fc12.i686 freetype-2.3.9-6.fc12.i686 xorg-x11-server-Xorg-1.7.1-9.fc12.i686 Additional info: $ gconftool-2 -a /desktop/gnome/font_rendering antialiasing = grayscale hinting = slight dpi = 96 rgba_order = rgb Changing these settings only make minor differences. I have an AL2016W LCD screen connected with a VGA adapter (HDMI is not available), I hope this is not relevant here. I'm running at 1600x1200@60 Disabling KMS does not seem to make a difference. Changing the driver back to radeonhd does not seem to make a difference, so I wonder if this was related to the F12 upgrade or its subsequent updates. Creating a new test user and logging in has the same result.
Created attachment 374585 [details] Xorg.0.log
Created attachment 374586 [details] smolt profile
Created attachment 374587 [details] xorg.conf -- nothing special here
Please do not use JPEG for screenshots. It uses lossy compression even with high quality setting. Use PNG with lossless compression instead. Some people prefer fonts which look close in shape to how they were designed even at the cost of some blurriness. Other people prefer crisp fonts with pixel-aligned lines even at the cost of distortion. Since you seem to belong in the second group, perhaps you should try stronger hinting and subpixel aa? I wonder if you were using a modified freetype library with the patented bytecode interpreter enabled from a certain external repo in F11?
In F11 I appear to have used freetype-2.3.9-5.fc11.i586, so bytecode shouldn't have been used. I can do a new screenshot if necessary (I set the JPEG quality to 100%) in a couple of days. As I mentioned, full hinting and subpixel aa didn't have significant impact on the crispness.
Hm, for me the appearance changes very significantly when I change the settings. Did you restart Firefox after changing the settings? Unlike Gnome applications, it is not clever enough to adjust its drawing at runtime.
Hi there. I think I'm seeing the same thing. I've got a few observations to make: would you mind seeing if you see the same? If I use the radeon driver (e.g. from a Fedora 12 x86_64 live image, although this also happens if I choose the radeon driver in my existing Fedora 12 install), turn font rendering to monochrome (i.e. no anti-aliasing/smoothing) and look closely at the screen, the display is still fuzzy. If I look really closely at black-on-white text (e.g. in gnome-terminal), the pixel to the right of each vertical stroke is grey. If I take a screen shot and zoom right in, however, this does *not* come across in the screen-shot: the data in the screenshot is evidently monochrome. If I look at it with the radeon driver at normal resolution, however, we're back to fuzzy fonts. If I set the driver to radeonhd, the fonts are as crisp as I specify. The pixels in a gnome-terminal using monochrome font rendering are either white or black. (To do this I need to put nomodeset on the kernel command line and come up with a minimal xorg.conf. Pekka, are you sure that you actually got X to use the radeonhd driver?) My xorg.conf: Section "Device" Identifier "foo" Driver "radeonhd" Option "DRI" "off EndSection I am using a DGM LCD monitor at the auto-detected 1440 x 900 native resolution through a VGA cable. I use x86_64. The display with the radeon driver gives my eyes eye-strain: I do not consider it usable. I think that the fuzziness is there on all vertical lines. I'm pretty sure it isn't a font rendering artifact. (Next time I have the time to reboot, I'll see what a vertical line in the GIMP looks like.) $ lspci | grep VGA 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon HD 3200 Graphics $ lspci -n | grep 01:05.0 01:05.0 0300: 1002:9610 Thanks for your attention.
Michal: If I turn on full hinting and subpixel AA and restart firefox, crispness does not increase significantly. The font changes noticeably but that's it. Turning to "monochrome", it's ugly and also smudgy. I don't see grey to the right of vertical strokes; I do see grey usually below or above horizontal lines. This also disappears in a really close zoomed screenshots. It's just black there. I'm pretty sure about radeonhd, but I'll retest and report if there was a difference. I'll attach a PNG screenshot (pretty big..) when full hinting and subpixel AA had been turned on and firefox had been restarted.
Created attachment 375212 [details] screenshot w/ full hinting and subpixel anti-aliasing.
Thanks for using PNG instead of JPEG this time. You misunderstood what I meant by lossless compression though. PNG uses lossless compression even if you set the "Compression level" slider in the "Save as PNG" dialog in Gimp to its maximum (9). The result would be only 441 KB and still pixel-perfect. Please use this setting for any future screenshots. On my display the fonts in your screenshot look good to me. Do you have a chance to view your screenshot on another computer, preferably with a fully digital path to the display (DVI or HDMI, not VGA)? Would you say it looks better there? I am asking this to rule out subjective font appearance perception. If it looks good when viewed on another system, this would confirm James's observation that the pixels are correct and the fuzziness is introduced somewhere further in the signal path. It seems the radeon driver is driving the VGA DAC suboptimally. There could a real difference between how radeon and radeonhd do it.
I looked at it on another system, and the quality is much better, the main fonts are sharp. The smallest fonts are not very good, but I'm not sure if it would even be possible. RadeonHD is also showing the same behaviour as radeon. One difference in xorg.conf (in F11) was that I had manually defined the monitor's sync values. During testing, xorg.conf was rewritten and these were lost. Autodetected values look OK, but I could try to find an earlier copy of xorg.conf or try to type them manually even though the monitor and its refresh values are autodetected.
Created attachment 375574 [details] screenshot w/ "best shapes" option
I'll add that if I switch to 1680x1050 mode, the smudginess goes down to a bearable level. The fonts seem "stretched out" though, having been used to 1600x1200.
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Looks like my problem was a different issue. The radeon driver must drive the VGA output differently to radeonhd: I hadn't expected that the phase control on the monitor would need to be tweaked for the different driver. Intriguingly, the smudginess was even there in a hi-res console! James.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This still appears with 1600x1200 mode in F14. Going back to 1680x1050.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping