Re: Metacity changes to paint ARGB window titles correctly

[Havoc Pennington <hp redhat com>]

Hi,

Looks pretty gross. ;-)

The reason metacity uses one GtkWidget for all the frames is that
GtkWidget is fairly big. I try pretty hard to keep per-window overhead
as low as I can, with moderate success. Per-window overhead is what
kills you in overall WM overhead.

One a quick read and looking at how gtk_style_attach() works, your patch
is going to create a whole lot of copies of GtkStyle that are exactly
the same. When a frame has the same visual as MetaFrames::style you just
ref that style, but when a frame has a different visual you'll make a
new copy - but the new copy is per-frame, not per-visual. Ergo lots of
new copies made.

So I think we need to go per-visual. There are two ways I can see to do
that, maybe there are more.

1. Make a MetaFrames per-visual
2. Make a GtkStyle per-visual


Approach 1 - widget per visual
===

I guess you'd make MetaUI::frames in ui.c into an array or something.
One complexity with that are all these type of functions:

void
meta_ui_queue_frame_draw (MetaUI *ui,
                          Window xwindow)
{
  meta_frames_queue_draw (ui->frames, xwindow);
}

Suddenly you'd need to find the right ui->frames[n] before you could
call queue_draw. The caller of these functions probably always has a
MetaWindow::xvisual though (typically someone's passing in
MetaWindow::xwindow) so a working if grotty hack would just add a Visual
arg to meta_ui_*; or perhaps you could make the
map<xwindow, MetaUIFrame> be in ui.c instead of part of MetaFrames.
Or other ideas.

Approach 2 - style per visual
===

You'd basically change your current patch to have a map<visual,style> in
MetaFrames, rather than a style field in MetaUIFrame.

My only misgiving here is unhappiness about poking crap into 
widget->style under GTK's nose (a feature your current patch also has);
so to use this approach I think we need to ask Owen or Matthias if it's
going to work.

Havoc