Bug 190627 - Sub-pixel hinting enabled although it is disabled in systemsettings
Summary: Sub-pixel hinting enabled although it is disabled in systemsettings
Alias: None
Product: kde
Classification: I don't know
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Unspecified
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
: 190905 194000 303229 (view as bug list)
Depends on:
Reported: 2009-04-25 15:54 UTC by Alex Dănilă
Modified: 2013-07-12 03:10 UTC (History)
12 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:

Plasma and kwin colour fringes (89.53 KB, image/png)
2009-04-25 15:56 UTC, Alex Dănilă
KWin menu and Kate (16.98 KB, image/png)
2009-04-25 15:58 UTC, Alex Dănilă
Blue fringes in the window title, while menu is OK (4.85 KB, image/png)
2009-07-02 02:04 UTC, handzisk
konsole test (58.00 KB, image/png)
2009-07-03 09:51 UTC, vpiotr
KDE 4.4.4 - menu & task manager - air_subpixel (64.16 KB, image/png)
2010-06-07 16:06 UTC, Taras Puchko
KDE 4.4.4 - menu & task manager - air_grayscale (63.44 KB, image/png)
2010-06-07 16:07 UTC, Taras Puchko
KDE 4.4.4 - menu & task manager - oxygen_subpixel (55.92 KB, image/png)
2010-06-07 16:08 UTC, Taras Puchko
KDE 4.4.4 - menu & task manager - oxygen_grayscale (55.80 KB, image/png)
2010-06-07 16:09 UTC, Taras Puchko
Homerun Launcher Plasma Widget showing poorly rendered fonts alongside same text typed and copied from Kate, with nicer font rendering. (62.31 KB, image/png)
2013-07-11 03:44 UTC, PJSingh5000
KDE IM Contacts (kde-telepathy) showing poorly rendered fonts i nthe conversation pane alongside same text typed into the message input textbox, with nicer font rendering. (34.97 KB, image/png)
2013-07-11 03:44 UTC, PJSingh5000
Kick Off Launcher Plasma Widget showing poorly rendered fonts alongside same text typed and copied from Kate, with nicer font rendering. (78.41 KB, image/png)
2013-07-11 03:45 UTC, PJSingh5000

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Dănilă 2009-04-25 15:54:25 UTC
Version:            (using KDE 4.2.2)
Installed from:    Debian testing/unstable Packages

Plasma applets and kwin Decoration feature sub-pixel hinting, altough it is not explicitly enabled in systemsettings.

So i would like to be able to enable only simple antialias, without sub pixel hinting.
The attached pictures show the difference.
Comment 1 Alex Dănilă 2009-04-25 15:56:24 UTC
Created attachment 33091 [details]
Plasma and kwin colour fringes

Notice that the taskbar has colour fringes, the decoration too, but the inside of Kate window does not.
Comment 2 Alex Dănilă 2009-04-25 15:58:07 UTC
Created attachment 33092 [details]
KWin menu and Kate

Notice that the decoration menu (Alt+F3) has colour fringes, while Kate menu does not. You may need to magnify the image.
Comment 3 Jonathan Thomas 2009-05-06 03:46:10 UTC
*** Bug 190905 has been marked as a duplicate of this bug. ***
Comment 4 Aaron J. Seigo 2009-05-25 09:53:31 UTC
*** Bug 194000 has been marked as a duplicate of this bug. ***
Comment 5 handzisk 2009-07-02 02:04:39 UTC
Created attachment 34984 [details]
Blue fringes in the window title, while menu is OK

I can confirm the bug on KDE 4.2.4 on Fedora 11. The subpixel rendering is disabled on the system but the window title shows very nasty blue fringe. The menu text is correct, using only grayscale.
Comment 6 Christoph Feck 2009-07-02 17:16:41 UTC
This may be a bug in Qt that forces subpixel hinting for ARGB windows. Could you test application "Konsole" and report your findings?
Comment 7 vpiotr 2009-07-03 09:51:07 UTC
Created attachment 35011 [details]
konsole test

Tested with konsole, see attachment:

 * image on the left - subpixel rendering switched off
 * image on the right - subpixel rendering set to RGB in system settings


Qt: 4.5.2
KDE: 4.2.4
Konsole: 2.2.3
X.Org X Server 1.5.3
X.Org opensource ati driver 6.12.1 (with RV280 [Radeon 9200 PRO])

Additional note:

I don't experience this issue on a machine with the same set of software but running on NVidia GeForce 6600 with nvidia binary driver
Comment 8 Taras Puchko 2009-11-09 18:08:49 UTC
On Kubuntu 9.10 with KDE 4.3.2, the same is on Fedora 21 beta:

1. Sub-pixel rendering enabled and the air theme selected: black text on gray taskbar is using grayscale rendering.

2. Sub-pixel rendering disabled and the oxygen theme selected: white text on dark taskbar is using sub-pixel rendering.
Comment 9 meloon 2010-01-02 15:21:26 UTC
I could reproduce this bug using KDE SC 4.3.4 and Qt 4.5.3
Comment 10 Christoph Feck 2010-01-02 15:43:33 UTC
A few days ago I tried screen rotation with xrandr. Since this will change RGB subpixel order, I changed from RGB to BGR in systemsettings. However, newly started applications did not pick up that change. Then I changed it back to RGB, and suddenly, newly started applications appeared in BGR! Changing back to BGR made them appear in RGB again. When I hit "Apply" without changing anything, then the "nothing changed" is still picked up, and applications start with the last set mode.

So in total, it looks like there is some caching done inside fontconfig, which makes it respect settings delayed. It could be an upstream issue.
Comment 11 Christoph Feck 2010-01-02 15:47:04 UTC
Additional notes: This would also explain differing font sizes in KWin with respect to other applications. When settings are applied delayed, KWin as the first application that uses fonts might get different settings than all other applications started later. I remember there was a bug report, but cannot remember right now.
Comment 12 Christoph Feck 2010-01-13 14:03:16 UTC
I was referring to bug 179962.
Comment 13 Andrey Cherepanov 2010-03-02 10:41:31 UTC
*** This bug has been confirmed by popular vote. ***
Comment 14 Nicolas L. 2010-06-07 01:17:09 UTC
Can you reproduce using KDE 4.4.4 or 4.5beta?
Comment 15 Taras Puchko 2010-06-07 16:06:52 UTC
Created attachment 47783 [details]
KDE 4.4.4 - menu & task manager - air_subpixel
Comment 16 Taras Puchko 2010-06-07 16:07:57 UTC
Created attachment 47784 [details]
KDE 4.4.4 - menu & task manager - air_grayscale
Comment 17 Taras Puchko 2010-06-07 16:08:55 UTC
Created attachment 47786 [details]
KDE 4.4.4 - menu & task manager - oxygen_subpixel
Comment 18 Taras Puchko 2010-06-07 16:09:39 UTC
Created attachment 47787 [details]
KDE 4.4.4 - menu & task manager - oxygen_grayscale
Comment 19 Taras Puchko 2010-06-07 16:10:29 UTC
I'm running KDE 4.4.4 on Kubuntu 10.4 with Intel graphics.
I've attached 4 screenshots of the bottom left corner of the screen: air_subpixel.png, air_grayscale.png, oxygen_subpixel.png, and oxygen_grayscale.png.
There you can see an application launcher menu, a task manager and a part of a running application (Krusader).

The application (text "F4 Edit") is always rendered correctly according to the subpixel settings.
The menu does not depend on the settings - the application descriptions are always grayscale and everything else is subpixel-antialiased.
The task manager antialiasing depends on the current theme - it's grayscale on Air and subpixel-antialiased on Oxygen.
Comment 20 Robert Schedel 2011-01-02 11:53:46 UTC
On my system (KDE 4.5.4, Qt 4.7.1, Oxygen theme, subpixel rendering enabled, infinality subpixel patchset) I also observed that all ARGB related texts (i.e. those from plasma desktop in taskbar/desktop widgets) only had grayscale AA, but no subpixel AA.

After the assumption regarding an ARGB related bug, played a bit with ARGB test code. It looked as if the raster backend has difficulties with subpixel rendered texts. After changing Qt to the old native backend, all fonts were rendered correctly on my KDE desktop!

- Do you have the new Qt raster backend enabled?
- Can you please revert to the old native backend, for testing?

My guess is all of this is related to the raster backend. This ticket might have to do with it:
Comment 21 Christoph Feck 2011-01-21 00:58:25 UTC
Re comment #19 and comment #20:

What you are seeing is indeed a problem of the way text is rendered in Plasma. Some text (for example in the taskbar) is first rendered to an image to apply shadow and halo effects on it. Since with an image you do not know where it is displayed, and Qt cannot apply sub pixel hinting to text.

This bug, however, is about a completely unrelated issue. The first application(s) that uses text (usually the Plasma Workspace or KWin) completely ignores font related settings from .fonts.conf file, such as anti aliasing settings or font sizes. As the title says, it is therefor even possible that those applications _have_ sub pixel hinting enabled, while it is disabled in System Settings. I still think it is an upstream bug, see comment #10.
Comment 22 Baconmon 2011-12-06 18:18:39 UTC
I can confirm this in kde 4.6.5..

The inside of the application windows seem to honor the setting..
But every thing else plasma-related seems to have sub-pixel enabled, even though I have it disabled, and it looks ugly.. For example, the title-bar texts, and any menu related to plasma, like if I right-click on the desktop background, or task bar or system tray icons etc..

Weirdly, I think this only started happening now that I switched to the open-source radeon driver.. I was using nvidia proprietary for a while, and then I switched to an ATI card and started using fglrx......And finally, today I switched to the open-source radeon driver, and I am almost completely positive that this issue didn't happen on non-free nvidia, or the fglrx, but only after I started using radeon driver.. Otherwise I would have looked this bug up before today because sub-pixel hinting is very obvious (and very ugly) to me..
Comment 23 Baconmon 2012-05-16 18:56:26 UTC
I am now on KDE 4.7.4 and this issue still remains for me for plasma-related stuff.. (I am also still using open-source radeon driver, not sure if that has any thing to do with it or not..)
I am using debian testing..
Comment 24 owenswerk 2012-07-04 17:17:42 UTC
Comment #21 has it right!  Until this gets fixed, I use this hacky little script, anytime after KDE has started, and the nasty subpixel rendering in plasma/kwin goes away:

killall plasma-desktop
killall kwin
plasma-desktop &
kwin &

I don't know how those apps are managing to ignore every font config file in my system, or why they are then suddenly honored later in the KDE startup process.  I also think it's very rude for any application to default to subpixel rendering, which even on LCDs looks awful.  Whatever optical illusion the technique relies on is incompatible with my eyes, and I'm not the only one.
Comment 25 Baconmon 2012-07-04 22:21:58 UTC
I am on 4.8.4 now on debian testing, and the bug remains..
I agree with comment #24 that I don't like sub-pixel hinting even on my LCD monitor.. I can always tell when fonts have it some how.. Always has ugly cyan and magenta fringes..

It seems like it would be an easy and quick bug to fix once some one decides to work on it.. Because it seems like it can already do it if you restart plasma and kwin like comment #24 said....
Comment 26 Jurica Vukadin 2012-07-09 16:52:40 UTC
*** Bug 303229 has been marked as a duplicate of this bug. ***
Comment 27 PJSingh5000 2013-07-11 03:44:20 UTC
Created attachment 81051 [details]
Homerun Launcher Plasma Widget showing poorly rendered fonts alongside same text typed and copied from Kate, with nicer font rendering.
Comment 28 PJSingh5000 2013-07-11 03:44:53 UTC
Created attachment 81052 [details]
KDE IM Contacts (kde-telepathy) showing poorly rendered fonts i nthe conversation pane alongside same text typed into the message input textbox, with nicer font rendering.
Comment 29 PJSingh5000 2013-07-11 03:45:21 UTC
Created attachment 81053 [details]
Kick Off Launcher Plasma Widget showing poorly rendered fonts alongside same text typed and copied from Kate, with nicer font rendering.
Comment 30 PJSingh5000 2013-07-11 03:47:14 UTC
To each his own...  I like sub-pixel RGB font rendering.  Perhaps it's my eyes, or the LCD I am using, but I find the fonts to appear more crisp and smooth.

However, as this bug report implies, some parts of KDE display grayscale sub-pixel rendered fonts, while other parts of KDE obey (my) system-settings and display sub-pixel RGB antialiased fonts.  For example the text in Homerun, KDE IM Contacts (kde-telepathy), and Kick Off is fuzzy.  But the text in Kate or the text input box in KDE IM Contacts is rendered nicely.

I am running KDE 4.10.4 on an x64 on a machine with Intel graphics.  I have selected "native" for the QT Graphics system setting, but notice no difference between this and "raster."

I've attached some scren shots showing the difference.  In each of the screen shots, I've typed the same text in Kate, and pasted it alongside the font displayed by KDE to highlight the difference.  The screen shots are of Homerun (https://bugs.kde.org/attachment.cgi?id=81051), KDE IM Contacts (https://bugs.kde.org/attachment.cgi?id=81052), and Kick Off (https://bugs.kde.org/attachment.cgi?id=81053).

By the way, Owenswerk's script in Comment 24 (https://bugs.kde.org/show_bug.cgi?id=190627#c24) does nothing to correct this issue on my system.
Comment 31 Christoph Feck 2013-07-11 10:24:02 UTC
Please read comment #21, and report the issues separately to Plasma, KTelepathy, and Homerun developers.
Comment 32 PJSingh5000 2013-07-11 22:34:15 UTC

Thanks for your feedback.

I can open bugs against these specific application, but the issue is more prevalent, affecting many KDE applications, not just the example applications I cited (Homerun, KDE IM Contacts / kde-telepathy, and Kick Off).

Do you  think this is an issue with QT, or with Plasma (if these apps rely on some common Plasma component).
Or,.. is it true that the majority of applications written for KDE simply ~ignore~ font anti alias settings?!! (In which case, we would have to open a bug with almost every KDE application!).

I'd like to hit this bug at the root.  It might make more sense to open bug(s) against QT or Plasma.  What do you think?
Comment 33 Christoph Feck 2013-07-12 03:10:59 UTC
Report it for each application where you see it. Qt cannot be fixed, because rendering into a bitmap cannot add subpixel hinting, because Qt does not know which screen (if at all) the bitmap is going to be copied into.

The respective application developers can then decide to change the code not to render into a bitmap, but directly to the widget's painter. Or maybe they are using Plasma text rendering calls, without being aware of the issue. Or they use Plasma calls intentionally, to get the blurred shadows to be better readable with transparent themes.

You might point them to this bug report, especially comment #21 and comment #33.

Plasma developers could check, if rendering the shadows could be decoupled from rendering the text, but that might cause issues when the metrics does not match accurately.

Anyway, what you see is related, but a completely different issue what this bug is about. Since bug 260943 has been marked upstream, I will do the same for this one.