Created attachment 95938 [details]
Pink preview (Clearlooks)

Created attachment 95939 [details]
Pink preview (Glider, Glossy)

Created attachment 95940 [details]
Pink preview (SmoothGNOME)

Created attachment 95941 [details]
Pink theme variants (Clearlooks)

Created attachment 95943 [details]
Pink theme variants (Glider, Glossy)

Created attachment 95944 [details]
Pink theme variants (SmoothGNOME)

Created attachment 95945 [details]
Scrollbars, button and selection highlights are okay

Oops - gnome-control-center is 2.20.0, of course, not 2.12.0.

Just for you?
Probably you've something wrong in ~/.gtkrc-2.0

I'm the only user on my PC. I do however have a "gnome" test user account on the same PC, which is affected just the same way, even after I completely wipe out its home directory before logging in. Here's my ~/.gtkrc-2.0:

[zlatko@disclosure]:~$ cat .gtkrc-2.0
# -- THEME AUTO-WRITTEN DO NOT EDIT

include "/home/zlatko/.gtkrc-2.0.mine"
# -- Appended by GNOME Configurator
include ".gtkrc-2.0-scrollbar_cog"

[zlatko@disclosure]:~$ cat .gtkrc-2.0.mine
gtk-can-change-accels = 1
gtk-entry-select-on-focus = 1
gtk-theme-name = "Clearlooks"
gtk-icon-theme-name = "Tango"

# GAIM
binding "pidgin-bindings"
{
# enter inserts a newline
bind "Return" { "insert-at-cursor" ("\n") }
# ctrl-enter sends message
 bind "<ctrl>Return" { "message_send" () }
}
widget "*pidgin_conv_entry" binding "pidgin-bindings"

[zlatko@disclosure]:~$ cat .gtkrc-2.0-scrollbar_cog 
[zlatko@disclosure]:~$ 

Do you have any idea where else I could/should start looking? I'm pretty much at a loss here.

Appearance properties -> Customize -> Colors?

The colors are all at their default values, ie. the "reset to default" button is greyed out. If it was something low-level like this (ie. a bug in either GTK itself or gtk-engines, or some "leftovers" in a stray gtkrc somewhere), I'd guess that all other GTK controls (scrollbars, button highlights, shaded tabs, etc.) would be pink as well - but they aren't. It's *only* Metacity's window borders that are affected, as you can see in the screenshots.

What I found out meanwhile is that unless the HSV "V" value of the theme's selected_bg_color is 100, whatever color I pick gets a red tint. This happens even if I select a primary color, ie. blue (#0000ff) or green (#00ff00). These values are fine, and the window border colors are shown properly - but as soon as I change V to 99 instead of 100 (ie. #0000fc or #00fc00), the window borders turn plain red. The same happens if I mix two primary colors, ie. yellow (#ffff00 is fine, #fcfc00 is not) or cyan (#00ffff is fine, #00fcfc is not). It does *not* happen with magenta, though (both #ff00ff and #fc00fc are fine). OTOH, if I take Clearlook's default selected_bg_color (#86abd9) and crank up the HSV "V" value to 100 (#9dc9ff), then the window borders are actually blue instead of pink - but if I drop the "V" value only one notch to 99 (#9bc7fc), the window borders are all pink again.

I'll attach another set of screenshots to illustrate my findings.

Created attachment 96431 [details]
selected_bg_color #0000ff

Created attachment 96432 [details]
selected_bg_color #0000fc

Created attachment 96433 [details]
selected_bg_color #00ff00

Created attachment 96434 [details]
selected_bg_color #00fc00

Created attachment 96435 [details]
selected_bg_color #9dc9ff

Created attachment 96436 [details]
selected_bg_color #9bc7fc

So the hue information is getting lost somewhere and replaced with 0 in a lot of cases, that is weird ... maybe some shading bug inside metacity?

Just found another quite strange thing, which hints to a bug in gnome-appearance-properties, or more specifically in its way of interpreting and/or saving of the /desktop/gnome/interface/gtk_color_scheme gconf key. It somehow seems to duplicate (?) every byte of the color's RGB value - after setting Clearlooks' selected_bg_color to #9DC9FF (that's the default value with "V" cranked up to 100), here's what it looks like:

[zlatko@disclosure]:~$ gconftool-2 -g /desktop/gnome/interface/gtk_color_scheme
fg_color:#000000000000
bg_color:#ededececebeb
text_color:#1a1a1a1a1a1a
base_color:#ffffffffffff
selected_fg_color:#ffffffffffff
selected_bg_color:#9e15c9bbffff
tooltip_fg_color:#000000000000
tooltip_bg_color:#f5f5f5f5b5b5

Note that the actual color values according to Clearlooks' gtkrc which comes with gtk-engines should be #000 (#000000?), #edeceb, #1a1a1a, #fff (#ffffff? #0f0f0f? #fff000? #000fff? How does GTK actually interpret these 3-digit color definitions? The color selection dialog only allows "#" plus exactly 6 hex digits, so I can't actually tell ...), #fff, #9dc9ff (that's the one I modified), #000 and #f5f5b5. With selected_bg_color set to #9BC7FC ("V" = 99), it looks like this:

[zlatko@disclosure]:~$ gconftool-2 -g /desktop/gnome/interface/gtk_color_scheme
fg_color:#000000000000
bg_color:#ededececebeb
text_color:#1a1a1a1a1a1a
base_color:#ffffffffffff
selected_fg_color:#ffffffffffff
selected_bg_color:#9b9bc7c7fcfc
tooltip_fg_color:#000000000000
tooltip_bg_color:#f5f5f5f5b5b5

Still, I have no idea how this leads to the ugly pink I'm seeing (which lies somewhere between #d1xxxx and #e2xxxx according to GTK's own color picker), but something's definitely fishy here. Unfortunately gnome-appearance-properties deletes the gtk_color_scheme key if I hit the "reset to defaults" button, so I can't tell which values it sees with the unmodified default Clearlooks color scheme.

If any of this contains some dead giveaway (that I as a non-developer fail to properly recognize) as to where exactly the problem lies, feel free to reassign this bug to the proper GNOME component. Right now I suspect either gnome-appearance-properties for saving an invalid color definition value in the gtk_color_scheme key, or, if these 12-hex-digit color values are actually valid, metacity for not interpreting them properly.


PS: there's definitely something wrong with the color value saving. If I change the "V" value back to 100 again (ie. default -> "V"=100 -> "V"=99 -> "V"=100", the gconf key is different than before (selected_bg_color:#9e15c9bbffff -> #9e14c9bbffff), although gnome-appearance-properties shows the same color value (#9dc9ff) in the color selection dialog:

[zlatko@disclosure]:~$ gconftool-2 -g /desktop/gnome/interface/gtk_color_scheme
fg_color:#000000000000
bg_color:#ededececebeb
text_color:#1a1a1a1a1a1a
base_color:#ffffffffffff
selected_fg_color:#ffffffffffff
selected_bg_color:#9e14c9bbffff
tooltip_fg_color:#000000000000
tooltip_bg_color:#f5f5f5f5b5b5

*** Bug 460023 has been marked as a duplicate of this bug. ***

The longer 16bit per sample format is completely fine and I don't think this is related to the issue. Metacity never sees the colors set in the gtkrc, or the color scheme setting as it uses the colors from the GtkStyle struct.

I'll reassign the bug to metacity. I do not know whether this is a metacity bug or not, but I don't have any better idea.

Gosh, what an interesting-looking bug. I'll have a look over the weekend.

Thanks - I'm glad you like my pink bug. :-)

Some random points that may or may not be of importance:

1. I compiled metacity with --enable-compositor, but I'm currently running my X server with compositing turned off (ie. I don't have a line 'Option "Composite" "Enable"' in xorg.conf, and 'xdpyinfo | grep -i comp' is empty).

2. [zlatko@disclosure]:~$ locale | grep NUM
LC_NUMERIC=de_AT.UTF-8
That is, one-point-five is "1,5" in my locale, not "1.5" (GTK+ itself obviously handles it properly, but I thought I'd mention it anyway).

If you need to know anything else, just let me know.

"What I found out meanwhile is that unless the HSV "V" value of the theme's
selected_bg_color is 100, whatever color I pick gets a red tint."

We're experiencing what sounds like the exact same bug here, using Slackware 12.0. For the title bars to not be shaded pink one of red, green or blue has to be 255, or the red value has to be greater than (not equal to) the green value. If they are shaded pink the brightness of the pink depends on the brightness of the colour selected.

Happens if I compile metacity 2.14.3, 2.18.3, 2.18.5, or 2.2.20.0 on Slackware 12.0. Does not happen if I copy the compiled metacity 2.14.3 package from the Slackware 11.0 system we used last year.

Woo-hoo, *finally* - I'm not the only one experiencing this bug! :-)

Your comment about the relation between the red value and the green and blue values reminded me of a code snippet I recently saw in src/theme.c's gtk_style_shade(), rgb_to_hls() and hls_to_rgb(). For starters, I added a few debug statements to print the RGB values in these functions and calculations. And here's the kicker: as soon as I did this, the bug was gone - GONE! My window borders are blue again, exactly like they should be! WTF?

All I did was adding four lines in gtk_style_shade(), I didn't change any of the actual values:

g_debug("ZlatkO-[1234]: GdkColor = %d/%d/%d; red = %f, green = %f, blue = %f; k = %f", a->red, a->green, a->blue, red, green, blue, k);

"ZlatkO-1" is right before the rgb_to_hls() call in gtk_style_shade(), "ZlatkO-2" is right after the call. "ZlatkO-3" is right before the hls_to_rgb() call, "ZlatkO-4" is right after. Here's some snippets of the massive output this produces (not to mention the extreme slowdown when drawing the window borders) in the hopes that the metacity developers get some hint out of it as to where the problem lies - do the color conversions look right (they probably do, or else my window borders would still be pink, I guess)?


(metacity-theme-viewer:2568): metacity-DEBUG: ZlatkO-1: GdkColor = 34438/43947/55769; red = 0,525490, green = 0,670588, blue = 0,850980; k = 0,980000
(metacity-theme-viewer:2568): metacity-DEBUG: ZlatkO-2: GdkColor = 34438/43947/55769; red = 213,253012, green = 0,688235, blue = 0,522013; k = 0,980000
(metacity-theme-viewer:2568): metacity-DEBUG: ZlatkO-3: GdkColor = 34438/43947/55769; red = 213,253012, green = 0,674471, blue = 0,511572; k = 0,980000
(metacity-theme-viewer:2568): metacity-DEBUG: ZlatkO-4: GdkColor = 34438/43947/55769; red = 0,507939, green = 0,656413, blue = 0,841002; k = 0,980000


(metacity-theme-viewer:2568): metacity-DEBUG: ZlatkO-1: GdkColor = 34438/43947/55769; red = 0,525490, green = 0,670588, blue = 0,850980; k = 1,160000
(metacity-theme-viewer:2568): metacity-DEBUG: ZlatkO-2: GdkColor = 34438/43947/55769; red = 213,253012, green = 0,688235, blue = 0,522013; k = 1,160000
(metacity-theme-viewer:2568): metacity-DEBUG: ZlatkO-3: GdkColor = 34438/43947/55769; red = 213,253012, green = 0,798353, blue = 0,605535; k = 1,160000
(metacity-theme-viewer:2568): metacity-DEBUG: ZlatkO-4: GdkColor = 34438/43947/55769; red = 0,676249, green = 0,785113, blue = 0,920457; k = 1,160000


(metacity-theme-viewer:2568): metacity-DEBUG: ZlatkO-1: GdkColor = 60909/60652/60395; red = 0,929412, green = 0,925490, blue = 0,921569; k = 0,450000
(metacity-theme-viewer:2568): metacity-DEBUG: ZlatkO-2: GdkColor = 60909/60652/60395; red = 30,000000, green = 0,925490, blue = 0,052632; k = 0,450000
(metacity-theme-viewer:2568): metacity-DEBUG: ZlatkO-3: GdkColor = 60909/60652/60395; red = 30,000000, green = 0,416471, blue = 0,023684; k = 0,450000
(metacity-theme-viewer:2568): metacity-DEBUG: ZlatkO-4: GdkColor = 60909/60652/60395; red = 0,426334, green = 0,416471, blue = 0,406607; k = 0,450000


(metacity-theme-viewer:2568): metacity-DEBUG: ZlatkO-1: GdkColor = 34438/43947/55769; red = 0,525490, green = 0,670588, blue = 0,850980; k = 0,700000
(metacity-theme-viewer:2568): metacity-DEBUG: ZlatkO-2: GdkColor = 34438/43947/55769; red = 213,253012, green = 0,688235, blue = 0,522013; k = 0,700000
(metacity-theme-viewer:2568): metacity-DEBUG: ZlatkO-3: GdkColor = 34438/43947/55769; red = 213,253012, green = 0,481765, blue = 0,365409; k = 0,700000
(metacity-theme-viewer:2568): metacity-DEBUG: ZlatkO-4: GdkColor = 34438/43947/55769; red = 0,305724, green = 0,462676, blue = 0,657806; k = 0,700000


Too bad I can't use this as a temporary fix - the slowdown is just too massive ... :-/

Silly question, perhaps, but did you then try removing those debug lines, recompiling, and trying again?

Hmm, maybe a broken optimization in (some versions of) the GCC compiler?

Two clues:
 - two same-versioned metacity on Slackware seem to differ (one has bug, one does not)
 - adding print statements fixes it

So, it seems likely to relate to how the compiler is generating code. While I'm not an expert, one possibility is that the floating point registers on x86 are not the same size as a double in memory, so whether a register is used can affect the exact values you get.

Maybe the first step is to track down exactly which lines of code are involved, maybe floats aren't even the problem.

some double/gdouble errors?

Thomas: I just did that, and the bug is back - pink window borders all over again.

What I did find out, though, is that having only one of the four debug lines (doesn't matter which one) is enough to "fix" the problem. The slowdown is also greatly reduced this way (duh!), but still quite noticeable.

To put it in very non-technical terms, it almost seems like something has to "touch" or "look at" these values to "make them stick", or else they "somehow get lost", and pink window borders appear.


Benjamin, Havoc: gcc-4.1.2, Intel P4/3.2GHz (single core, hyperthreading), 2.6.22.9 SMP kernel

[zlatko@disclosure]:~$ gcc --version
gcc (GCC) 4.1.2
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[zlatko@disclosure]:~$ cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 3
model name      : Intel(R) Pentium(R) 4 CPU 3.20GHz
stepping        : 4
cpu MHz         : 3207.494
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pni monitor ds_cpl cid xtpr
bogomips        : 6416.95
clflush size    : 64

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 3
model name      : Intel(R) Pentium(R) 4 CPU 3.20GHz
stepping        : 4
cpu MHz         : 3207.494
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pni monitor ds_cpl cid xtpr
bogomips        : 30913.47
clflush size    : 64


[zlatko@disclosure]:~$ uname -a
Linux disclosure 2.6.22.9 #1 SMP Thu Sep 27 08:11:47 CEST 2007 i686 Intel(R) Pentium(R) 4 CPU 3.20GHz GenuineIntel GNU/Linux


Current GNOME related version info: gtk+-2.12.1, gtk-engines-2.12.2, gnome-themes-2.20.1, metacity-2.20.0.

Incidentally, the same code seems to be cut-and-pasted in colors.c, not sure if it's still used. I looked at the gtkstyle.c copy in gtk and it looks the same, so any bugfix should go in all three copies (and/or kill off at least one of the copies...)

One thing to try is adding "volatile," 
  volatile gdouble red;
  volatile gdouble green;
though, I don't think that's really the right fix, it would be interesting if it also makes the problem go away.

Seems to be the a->red, a->green and a->blue values that cause the problem - printing only these also works, while printing only the (local) red, green and blue values does not.

Havoc: Add "volatile" where, exactly? In gtk_style_shade(), in rgb_to_hls(), or in both? Why only red and green, but not blue?

red and green were just examples. I meant in whatever function you added the print statements to. If the problem seems to be the integers (a->red, etc.) and not the floats though, then I doubt the volatile on the floats will do anything.

Ha, gotcha! :-)

I'll attach a patch that fixes the problem for me. It's probably a really bad and evil hack, but hey, my window borders are blue again!

This patch fixes all themes that had the pink tint before (see my screenshots), including *all* the previews in gnome-appearance-properties' Theme -> Customize -> Window Border tab, and *almost* all preview thumbnails in gnome-appearance-properties' Theme tab. Almost? Why, yes, for some strange reason, the preview thumbnails of Industrial-Squared (which is actually an older OpenBox theme, but it comes with a Metacity version as well) and SmoothGNOME still have the pink tint. It's only the preview thumbnail, though, if I actually select the theme, the window border colors are okay. Oh well ...

Created attachment 97492 [details] [review]
Possible fix

Any theory why that patch works ;-) ??? I'd be pretty reluctant to put it in without an explanation.

Nope, I don't have the slightest idea, sorry. It was just something that I tried more or less intuitively ("Well, if gtk_style_shade() screws up a->r/g/b, then I'll only give it a copy of a, that'll teach him!"), and it happened to work.

Given that I own one of exactly two (so far) systems world-wide that happen to be bitten by this strange bug, I simply accept the fact that the fix is just about as strange as the bug itself. :-)

Thomas, could you try recompiling with the "-O0" option to disable compiler optimization and see if that fixes it?

Done that (export CFLAGS="-O0"), works fine as well. I guess that's a better workaround than my obscure patch - thanks! :-)

OK, I assume this is a compiler optimization bug then. Marking as not gnome.

Just to confirm the same on my system.

Compiling with gcc-4.1.2 with -O1 or -O2 gives the bug. Compiling with gcc-4.1.2 with -O0, or with gcc-3.4.6 and any optimisation level, does not give the bug.

fwiw I don't think "it goes away without -O2" means it's a compiler bug. If our code is wrong in certain ways, it can certainly break with optimization and not break without.

However, I certainly don't have a guess why our code is wrong here, so without a compiler expert to help closing the bug is probably fine, at least until/unless this bug starts to turn up for more people.

Richard, Thomas: Can you confirm whether this happens with the latest GCC (4.2.2 -- http://gcc.gnu.org/gcc-4.2/ )? If so, I would recommend telling the GCC folks about it (or, if you'd rather, I will), since it's probably a bug that will bite other people in subtle ways. If you don't have time to compile 4.2.2 and test it but you'll give me shell access on a machine that's misbehaving with 4.1.2, I'll give it a go. If you do raise a bug against 4.2.2, please post a link to it here so that people finding this problem can find out what was done about it.

gcc devs aren't going to be able to do anything without a simple test case they can compile...

Thomas: Yup, same problem with gcc-4.2.2 (self-compiled on Slackware 12.0).

I'd rather not file a GCC bug myself, though, as I simply don't know Metacity's internals enough to be of any help, let alone GCC's. All I actually know about this problem is that "Metacity has pink window borders if I compile it on Slackware 12.0 with either gcc-4.1.2 or gcc-4.2.2, unless I compile it without optimization using '-O0' and/or use an obscure patch I stumbled across by pure accident". I seriously doubt that this would be any motivation for the GCC devs to dig deeper into the problem, especially as there is no actual proof yet that this is in fact a GCC bug. ;-)

Created attachment 108422 [details]
Darklooks colored window borders

It wasn't until I installed gnome-themes-extras with the Darklooks theme (lower left in the Theme tab) that all window borders in the Window Border tab started to be tinted dark.

I don't know if this effects the resolution of this bug, but I find it strange. (I.e. less likely to be a compiler bug... but who knows...)

This problem still occurs with:

Metacity 2.22.0
gcc 4.2.3
Ubuntu Hardy 8.04
Intel Diamondville (lpia arch)

Compiling without optimisations or with the gdk_color_copy hack restores the colours.

I wonder whether this is actually a gdk bug.

I am able to reproduce this on Ubuntu 8.04 (same setup as Neil Patel).  As a test, I built ui/theme.c using gcc 4.3.2-1ubuntu11 (everything else unchanged) and the problem vanished.  I think this makes it reasonably likely that this was a gcc optimization bug which was fixed between 4.2.3 and 4.3.2.