| Summary: | odd red tint in some places | ||
|---|---|---|---|
| Product: | [Plasma] Oxygen | Reporter: | Michael Kreitzer <mrgrim> |
| Component: | style | Assignee: | Matthew Woehlke <mwoehlke.floss> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
konversation 1.2alpha2 example
akregator web browser showing slashdot example Checkboxes at: http://www.qtsoftware.com/downloads/linux-x11-cpp Frame in Shaman package manager system settings > appearance -> colors -> disabled test case |
||
|
Description
Michael Kreitzer
2009-06-07 05:43:23 UTC
Created attachment 34337 [details]
konversation 1.2alpha2 example
Created attachment 34338 [details]
akregator web browser showing slashdot example
Created attachment 34488 [details] Checkboxes at: http://www.qtsoftware.com/downloads/linux-x11-cpp I'm running the most current nvidia beta driver in this screenshot. I'm not sure if it's even a driver issue. I'm at a loss of even how to begin searching for what's causing this. Created attachment 34490 [details]
Frame in Shaman package manager
last one, I promise
Created attachment 34707 [details]
system settings > appearance -> colors -> disabled
I went digging through the KDE/Qt code to try to find the source of this. I started with the Konversation custom widget which is based on the K3ListView. I tracked the frame drawing code to Q3Frame which uses an internal function in QFrame to do the drawing. This uses the Dark color role to determine the color to add a sunken effect. Which leads to the attached file...
The image is from the Disabled tab of the Colors section of the Appearance system settings category. The pink area is White when Intensity is set to None. Setting it to Darken causes the green and blue values to be decreased, but red remains at 255 causing the pink you see. I believe this is related to the rest. How it is related or why this is happening is still beyond my reach. I will continue looking, but some pointers would be much appreciated. The Qt Brush/Palette/Color code is unexpectedly complicated.
Created attachment 34708 [details]
test case
The culprit appears to be KColorUtils::darker. The attachment contains a bare minimum test case. I attempt to darken (255,255,255) by 0.1. The test program prints the RGB value of the color before and after darken. The output is as follows:
[mrgrim@mrgrim tmp]$ ./qcolor
255 255 255
255 240 240
I've tested this on KDE 4.2.4 and Qt 4.5.1
Thanks for invesigating. Trouble is that the bug is assigned to the wrong people. Try to contact Matthew Woehlke. He is the person I hope will be able to shed some light on this. Fortunately I noticed http://reviewboard.kde.org/r/868/ posted to k-c-d. If you like, please check if my suggested fix works for you. Hopefully we will get this patched soon :-). (In the future, please just CC me or (if bugzilla allows it) add me to the bug's CC list. Or, you know, assign it to me ;-). For something like this, I don't mind!) FWIW the "why" in said patch sounds correct. 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 |