Comment #31 on issue 10949 by [email protected]: Use GTK widget renderering in web content http://code.google.com/p/chromium/issues/detail?id=10949
It is very difficult to get exactly the same look as the native theme, as we do not have access to the actual theming engine from within the renderers. And theming engines are essentially at liberty to do pretty much anything they want. So, short of doing the expensive round-trip to the browser for each and every drawing operation, there is no way we can ever get the exact same pixel values. In general, we have to be able to do the right thing, independent of whether the user selected a light theme, a dark theme, a high-contrast theme, or maybe a theme that has non-rectangular and textured UI elements. What we do now is to ask GTK to render both a slider and track for us. We do this once at startup. In most cases, these representative examples of sliders and tracks will render exactly the same as the theme, but in some cases the theming engine does more complicated things, and the rendered pixel that we get are different from the ones that would normally be drawn by the theming engine. Those are the cases where you see colors diverge more than you would normally see in other themes. Once we have these pixels, we then try to find a region within the set of pixels that is relatively representative of the whole. This is complicated by the fact that some theming engines draw borders of various thickness around the UI elements, whereas others don't (or maybe just use transparency). Also, some theming engines include textured elements, whereas others don't. The upshot is that we can typically determine the average color for slider and track, but we cannot reliably determine the border color at all. After all, some themes might not even have a border. We also cannot determine any textures that are added to the corners or the middle of the slider. Overall, we end up just averaging pixel values, and then using them to determine the colors that we will use when drawing our slider and our track. As we have no way of computing border colors, that reliably gives correct results with all themes, we don't even try. Instead, we use code that determines visually pleasing border colors for all possible combinations of slider and track colors. For some themes, this border color will happen to be pretty close to the native look. For other themes, it can be wildly different. This would be particularly true for high-contrast themes that deliberately pick borders that differ a lot from all the other colors. Our goal with this change was not to match the native look 100%, but instead to provide a look that blends in nicely with the native look. This is in line with the rest of Chrome's UI which often subtly differs from the native look, but overall makes an attempt to fit in. I could certainly tweak the algorithm for picking border colors. But after testing with a large number of themes, I have come to the conclusion that no matter what we do, it will always look wrong for at least some themes. The values that I finally settled on are a compromise that works OK for most of the mainstream themes. It is somewhere between light and moderate contrast. Both light and moderate contrast themes appear to be in very common use, so this is good. If you prefer a high-contrast theme, you are unfortunately out of luck. This algorithm cannot represent that choice. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings -- Automated mail from issue updates at http://crbug.com/ Subscription options: http://groups.google.com/group/chromium-bugs
