Update RenderPreferences on GTK change.

Only calculate the GTK scrollbar colors once and then update all RenderPreferences on theme change.

BUG=10949
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=35712

[Elliot Glaysher, 2010-01-05 01:26:37]

I am not sure about this approach. Specifically, it looks like estade went out
of his way to make sure that gtk_util::InitRendererPrefsFromGtkSettings was only
called once, instead of per TabContents but I've been dissatisfied with every
attempt to only call InitRendererPrefsFromGtkSettings so far.

I'm not sure about RendererPreferences in general; it seems to mix immutable
state about the current browser (|browser_handles_top_level_requests| and
|can_accept_load_drops|) and preferences that can and do change (all the
antialiasing and color stuff).

Alternative idea to this patch (that would take a long time to do, compared to
this quick and simple hack): Merge the color/antialiasing information into
WebPreferences (contains preferences that change), simplify RendererPreferences
(contains immutable browser state), and rewrite how we send WebPreferences to
the renderer (the current code dates back to when web_contents.cc was the
dominant class and could be cleaned up conceptually...) so that there's one
WebPreferences instance passed to all renderers...

[Evan Stade, 2010-01-05 01:34:56]

can you just clobber the static rendererprefs thing once in gtkthemeprovider
before sending BROWSER_THEME_CHANGED

[Elliot Glaysher, 2010-01-05 01:46:07]

On 2010/01/05 01:34:56, Evan Stade wrote:
> can you just clobber the static rendererprefs thing once in gtkthemeprovider
> before sending BROWSER_THEME_CHANGED

This doesn't fix the clobbered state problem; we can't just
"TabContents::renderer_preferences_ = GetInitedRendererPreferences()" because we
would be clobbering the parts of RendererPreferences which aren't per desktop
preferences, but per Browser object preferences.

[Evan Stade, 2010-01-05 01:57:45]

I guess this patch is ok if it doesn't affect new tab perf. Do we have a test
for adding a new tab (not initial tab startup)?

[Elliot Glaysher, 2010-01-05 02:00:04]

I am not sure. Hence why I'm asking if either you or tony think I
should do it the long way (i.e. a major refactoring involving
WebPreferences).

On Mon, Jan 4, 2010 at 5:57 PM,  <estade@chromium.org> wrote:
> I guess this patch is ok if it doesn't affect new tab perf. Do we have a
> test
> for adding a new tab (not initial tab startup)?
>
> http://codereview.chromium.org/525016
>

[Evan Stade, 2010-01-05 02:03:10]

I think Tony is out on a long vacation.

seems like you could hack something together that just updates the part of the
rendererprefs that we care about (the bits affected by the gtk theme) which
would be less work than the major refactoring

[Elliot Glaysher, 2010-01-06 20:27:51]

Good idea. Here's it implemented. Take another look?

[Evan Stade, 2010-01-06 22:29:04]

http://codereview.chromium.org/525016/diff/35/1032
File chrome/common/renderer_preferences_linux.cc (right):

http://codereview.chromium.org/525016/diff/35/1032#newcode8
chrome/common/renderer_preferences_linux.cc:8: #include
"chrome/browser/gtk/gtk_theme_provider.h"
common/ can't depend on browser/

[Elliot Glaysher, 2010-01-07 00:19:47]

Fixed. (Or: so that's why you made renderer_preferences_util...)

[Evan Stade, 2010-01-07 00:27:24]

lgtm

http://codereview.chromium.org/525016/diff/6001/5006
File chrome/browser/renderer_preferences_util.cc (right):

http://codereview.chromium.org/525016/diff/6001/5006#newcode27
chrome/browser/renderer_preferences_util.cc:27: #endif
can you comment these endifs