Bug 194703 - [regression] pink background of kickoff scrollbar
Summary: [regression] pink background of kickoff scrollbar
Alias: None
Product: Oxygen
Classification: Plasma
Component: style (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Matthew Woehlke
Depends on:
Reported: 2009-05-31 03:03 UTC by Kamil Neczaj
Modified: 2009-06-22 22:39 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:

first (70.29 KB, image/png)
2009-05-31 03:04 UTC, Kamil Neczaj
second (14.17 KB, image/png)
2009-05-31 03:04 UTC, Kamil Neczaj

Note You need to log in before you can comment on or make changes to this bug.
Description Kamil Neczaj 2009-05-31 03:03:43 UTC
Version:            (using KDE 4.2.3)
OS:                Linux
Installed from:    Unlisted Binary Package

There is pink background of kickoff scrollbar if use default color scheme. Borders of text fields also are sometimes pink. Two screenshots attached.
Comment 1 Kamil Neczaj 2009-05-31 03:04:38 UTC
Created attachment 34138 [details]

This doesn't happen when using different color scheme than default
Comment 2 Kamil Neczaj 2009-05-31 03:04:58 UTC
Created attachment 34139 [details]
Comment 3 Kamil Neczaj 2009-05-31 13:13:48 UTC
I've forgot to mention that the background had proper colour in kde 4.2.2
Comment 4 Jonathan Thomas 2009-06-01 21:38:13 UTC
I can confirm this. The "disabled" palette also suffers from this bug.
Comment 5 Jan Mette 2009-06-21 12:15:40 UTC
Confirmed on trunk too. KDE 4.2.92 from yesterday / Qt 4.5.1 + latest qt-copy patches.
Comment 6 Michael Kreitzer 2009-06-21 12:19:52 UTC
I believe this is related to 195522
Comment 7 Michael Kreitzer 2009-06-21 12:22:04 UTC
I think there's a possibility this may be related to compiler versions and possibly compilation flags. If you know how your KDE was built please report it. If you do not at least list the specific binary packages you are using in case there is a possible correlation.
Comment 8 Jan Mette 2009-06-21 13:04:06 UTC
I am building my own packages, so no problemo. Here is some more info:

Compiler: GCC 4.4.0 20090526 (prerelease) (GCC)
C(XX)FLAGS: -march=i686 -mtune=generic -O2 -pipe

All in all i am using no weird optimizations, its all pretty generic.

Oh, and before i forget it: This happens on trunk since some weeks (around 4.2.8x if i remember correctly)
Comment 9 Jonathan Thomas 2009-06-21 13:50:16 UTC
Kubuntu 9.10 (in development) is using GC 4.4.0 too. Pretty generic compiler flags here, too.
Comment 10 Michael Kreitzer 2009-06-22 06:25:23 UTC
The problem is in the -ftree-pre compiler flag which is enabled when using -O2 on gcc 4.4. The use of this flag exposes a precision error in the constructor KHCY::KHCY(const &QColor). The result is an incorrect chroma value when luma should be 1.0. With this flag enabled the value on the FPU stack for luma is:

st1            0.99999999999999995836663657655662973    (raw 0x3ffefffffffffffffd00)                                                                                                                                       

This fails the "1.0 == y" condition in the if statement, and the chroma calculation is used and results in a "1.0" instead of the desired "0.0".

There are 2 possible solutions. First, the code can be refactored. I do not understand the color space conversion math yet so I've been unable to do so. Second, the -ffloat-store flag can be passed to the compiler to work around the issue as stated in GCC bug #323 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323).

I will continue investigating the color space conversion math to see if a code work around can be performed to avoid the special compilation flag. Hopefully I can provide a patch soon as eventually -O2 gcc 4.4 builds will become more common.

In the meantime, can someone with access move this bug to the appropriate project? The problematic source file is in the kdeui/color section of kdelibs.
Comment 11 Matthew Woehlke 2009-06-22 22:39:36 UTC
SVN commit 985441 by mwoehlke:

KHCY: Fix chroma calculation for grays which is sometimes (depends on compile flags) broken due to FP omtimizations. Improve kcolorutils test to catch these.

This should fix the pink/red tint glitches that have been reported. Some other QCOMPARE's in the test case are also adjusted (expected/actual values were swapped, and whitespace was wrong).

Many thanks to Michael Kreitzer for the analysis.

BUG: 194703
BUG: 195522

 M  +1 -1      colors/kcolorspaces.cpp  
 M  +34 -4     tests/kcolorutilstest.cpp  
 M  +1 -0      tests/kcolorutilstest.h  

WebSVN link: http://websvn.kde.org/?view=rev&revision=985441