Bug 195522 - odd red tint in some places
Summary: odd red tint in some places
Status: RESOLVED FIXED
Alias: None
Product: Oxygen
Classification: Plasma
Component: style (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Matthew Woehlke
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-07 05:43 UTC by Michael Kreitzer
Modified: 2009-06-22 22:39 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
konversation 1.2alpha2 example (13.32 KB, image/png)
2009-06-07 05:44 UTC, Michael Kreitzer
Details
akregator web browser showing slashdot example (4.42 KB, image/png)
2009-06-07 05:45 UTC, Michael Kreitzer
Details
Checkboxes at: http://www.qtsoftware.com/downloads/linux-x11-cpp (17.10 KB, image/png)
2009-06-13 02:21 UTC, Michael Kreitzer
Details
Frame in Shaman package manager (6.51 KB, image/png)
2009-06-13 03:26 UTC, Michael Kreitzer
Details
system settings > appearance -> colors -> disabled (16.67 KB, image/png)
2009-06-21 09:53 UTC, Michael Kreitzer
Details
test case (378 bytes, text/x-c++src)
2009-06-21 10:28 UTC, Michael Kreitzer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Kreitzer 2009-06-07 05:43:23 UTC
Version:            (using KDE 4.2.4)
OS:                Linux
Installed from:    Unlisted Binary Package

I'm not sure if this is oxygens fault, but I'm seeing an odd red tint in places. I have screenshots I'll attach with what I'm seeing in the frame around the konversation 1.2alpha2 tree based "tabs" as well as two buttons in the akregator integrated web browser (khtml?) showing a page from slashdot.

I've seen it in a couple of other weird spots as well, but I did not think to take screen grabs. There was a border in the yakuake config dialog that had this at some point.

I do not see this behavior on my laptop which uses intel graphics. My desktop, where I see this effect, is using the 180.51 nvidia graphics driver.
Comment 1 Michael Kreitzer 2009-06-07 05:44:54 UTC
Created attachment 34337 [details]
konversation 1.2alpha2 example
Comment 2 Michael Kreitzer 2009-06-07 05:45:34 UTC
Created attachment 34338 [details]
akregator web browser showing slashdot example
Comment 3 Michael Kreitzer 2009-06-13 02:21:54 UTC
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.
Comment 4 Michael Kreitzer 2009-06-13 03:26:23 UTC
Created attachment 34490 [details]
Frame in Shaman package manager

last one, I promise
Comment 5 Michael Kreitzer 2009-06-21 09:53:39 UTC
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.
Comment 6 Michael Kreitzer 2009-06-21 10:28:13 UTC
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
Comment 7 Camilla Boemann 2009-06-21 10:37:39 UTC
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.
Comment 8 Matthew Woehlke 2009-06-22 22:02:25 UTC
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.
Comment 9 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