Chromium Linux ignores background color on <select>. We always just draw the default gray gradient.
Created attachment 30682 [details] patch
Comment on attachment 30682 [details] patch Style issues. no { } on single line ifs. Don't we have a more efficient way to set this? paint.setARGB(o->style()->backgroundColor().alpha(), o->style()->backgroundColor().red(), o->style()->backgroundColor().green(), o->style()->backgroundColor().blue()); There should be a way to pass a Color object to a SkPaint, I'm sure we have such a function somewhere. color has a .rgb() accessor which probably returns a skpaint compatible int.
Created attachment 30881 [details] patch Changes: 1) Color::rgb does indeed return a value which is compatible. However, it seems be a bit of a leap that the internal format of both Color and SkColor is register ARGB. Other platforms define specific constructors in Color. However, both RGBA32 and SkColor unwrap to an unsigned int, so we can't do that here. I've used .rgb() because it works and it's cleaner. I guess layout tests will catch if either side ever changes. 2) html4.css was specifiying a default background-color for buttons which meant that we could never tell if the page was setting one (which we should observe) or not (in which case we should draw our default button). So I added a CSS snippet to override this.
I'm pretty sure I added a COMPILE_ASSERT in ColorSkia.cpp that ensures that the internal formats are identical. We could/should add an SkColor cast operator to Color as necessary though!
Comment on attachment 30881 [details] patch Still has the { } style issues. The .css file should be a real .css file on disk and go through the normal processing scripts, no? I think I would have written this: + if (!o->style()->hasBackground()) { + paint.setARGB(0xff, 0xe9, 0xe9, 0xe9); + } else { + paint.setColor(o->style()->backgroundColor().rgb()); + } As something like: static Color defaultButtonGrey(0xff, 0xe9, 0xe9, 0xe9); Color buttonBackground = !o->style()->hasBackground() ? o->style()->backgroundColor() : defaultButtonGrey; paint.setColor(buttonBackground.rgb()); But this makes me wonder if CSS buttons (which do not go through the button theme calls) will look correct w/o a background?
Created attachment 30920 [details] patch Next attempt: This time we remove all the magic colour values from the paintButtonLike function, except for a fallback colour. For painting <select>s and buttons, we generate the family of colours needed by converting to HSL and changing the luminance. With this in hand, we set the CSS ButtonFace colour and the <select> background-color and everything works out exactly the way is used to, except that <select>'s with background colours are now handled correctly. With this code, we could also handling drawing buttons with background-colors, but that's something for another patch.
Comment on attachment 30920 [details] patch I would have given this color a name: 129 return 0xffdddddd; static Color someNiceNameForTheColor(0xffdddddd); return someNiceNameForTheColor; Braces get their own line: 264 static float brightenColorCap(float in) { Single line ifs don't get braces: 292 if (max == min) { 293 hue = 0.f; 294 } else if (max == r) { Color functions belong on Color.h or somewhere in Skia... 282 static SkColor brightenColor(SkColor base, float brightenAmount) 256341 static void paintButtonLike(RenderTheme* theme, RenderObject* o, const RenderObject::PaintInfo& i, const IntRect& rect) { need { on its own line too. WK of course uses CamelCase: 334 int final_r = 255.f * brightenColorDecode(p, q, tr); Looks nice though! :) r- for color stuff needing to move somewhere else.
Created attachment 31019 [details] patch Moved the RGB->HSL conversion to Color and used the existing HSL->RGB conversion therein.
Created attachment 31020 [details] patch
Comment on attachment 31020 [details] patch Looks fine. Please add a ChangeLog when landing.
Comment on attachment 31020 [details] patch Why the round-trip through HSL? Can't you just make a version of Color::light() that takes a parameter?
Comment on attachment 31020 [details] patch See <http://trac.webkit.org/changeset/21798>.
Never mind, you want HSL, not HSV!
I could change Color::light, but the scaling of RGB components didn't work for me when I was playing around with different schemes. The colours I ended up with just didn't look quite right. I think HSL is the right way to do what I want here.
Comment on attachment 31020 [details] patch > + while (hue >= 360.0) > + hue -= 360.0; > + > + // makeRGBAFromHSLA assumes that hue is in [0...1). > + hue /= 360.0; What is the purpose of the while loop? > + lightness = 0.5f * (max + min); The "f" seems unhelpful at best. > + else if (lightness <= 0.5f) Ditto.
> What is the purpose of the while loop? The spec said "mod 360", which is most accurately turned into a while loop. Considering the case where max == r (which looks most likely to overflow 720 since it has the largest constant). We have hue = (60.0 * ((g - b) / (max - min))) + 360.0 so (g - b) / (max - min) must be < 6 in order not to overflow. We know that max > g and max > b (since max == r) and that min == g or min == b. Consider g >= b, thus b == min and thus g - b < max - min so the whole fraction is <= 1. The alternative case leads, via similar reasoning to the fraction being >= -1. So, we can change the while to an if. I'll do that. The f's were a left over from when I wrote it with floats. I'll remove them, thanks.
Landed in http://trac.webkit.org/changeset/44503.