| Summary: | [regression] pink background of kickoff scrollbar | ||
|---|---|---|---|
| Product: | [Plasma] Oxygen | Reporter: | Kamil Neczaj <kneczaj> |
| Component: | style | Assignee: | Matthew Woehlke <mwoehlke.floss> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | echidnaman, jan.mette, mrgrim, mwoehlke.floss |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
first
second |
||
|
Description
Kamil Neczaj
2009-05-31 03:03:43 UTC
Created attachment 34138 [details]
first
This doesn't happen when using different color scheme than default
Created attachment 34139 [details]
second
I've forgot to mention that the background had proper colour in kde 4.2.2 I can confirm this. The "disabled" palette also suffers from this bug. Confirmed on trunk too. KDE 4.2.92 from yesterday / Qt 4.5.1 + latest qt-copy patches. I believe this is related to 195522 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. 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) Kubuntu 9.10 (in development) is using GC 4.4.0 too. Pretty generic compiler flags here, too. 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. 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 |