Found rising RAM use (possible memory leak) in your branch 
supporting Metacity 3.22. After a few hours running and a
video editing session gwd was using 127MB of RAM. Restarting
it dropped it to 24.5MB, then opening and closing a half dozen 
windows raised it to 28.5 MB. 

Opening one Pluma window added 500kb to RAM used by gwd,
but closing it only freed 200MB. Similar behavior was observed
in Emerald, BTW. Wonder if some kind of issue outside the window
decorator (X itself maybe?) has a hand in this?

On 10/26/2016 at 6:02 AM, "Alberts Muktupāvels" <email address hidden> wrote:
>
>Not sure if I understand question... First gtk-window-decorator 
>can use
>cairo or libmetacity (previously libmetacity-private) to draw 
>window
>decorations. Gwd does not know anything about metacity themes, it 
>just
>use public API from libmetacity.
>
>https://git.gnome.org/browse/metacity/tree/libmetacity
>This library does all needed work - loads theme (from css or 
>metacity-theme-x.xml), calculates frame size, draws it...
>
>https://git.gnome.org/browse/metacity/tree/theme-viewer
>Theme viewer also use same library, just like metacity and gtk-
>window-decorator. So just study code if you want to know how 
>things works.
>
>-- 
>You received this bug notification because you are subscribed to 
>the bug
>report.
>https://bugs.launchpad.net/bugs/1629749
>
>Title:
>  window-decorator cannot build with libmetacity 3.22
>
>Status in Compiz:
>  New
>
>Bug description:
>  This is with compiz source 
>  compiz_0.9.13.0+16.10.20160818.2.orig.tar.gz
>  build on Debian Unstable (not Ubuntu) and GTK 3.22 and Metacity 
>3.22. Will become an issue for Ubuntu post-yakkety unless Ubuntu 
>pins Metacity at version 3.20.
>
>  Metacity/libmetacity 3.22 introduced radical changes that totally
>  break compiz's gtk-window-decorator,which can neither build nor 
>run
>  against it. I played with it, a whole bunch of things compiz 
>needed to
>  link against were removed. This was the first error resulting 
>from an
>  attempt to build against Metacity 3.22:
>
>  error: unknown type name ‘MetaButtonLayout’
>       MetaButtonLayout            button_layout;
>
>  
>  The possible killer for Metacity theme support:
>
>  
>https://github.com/GNOME/metacity/commit/d7f2445ec7e70274c7501586a5
>37c699f6628335
>  libmetacity: switch from .ssd to .csd 
>
>  and some of the changes probably behind breaking the build:
>
>  
>https://github.com/GNOME/metacity/commit/2ee0ffbee0b52cb8fc3112906b
>ea1eaa737559f7
>  libmetacity: don't expose MetaButton struct 
>
>  
>  
>https://github.com/GNOME/metacity/commit/eee199e3b7ce87cbd08b4b6e4c
>9c55c804c6ff5f
>  libmetacity: rename MetaButtonFunction to MetaButtonType 
>
>  Not sure a port to 3.22 would even still give the ability to read
>  Metacity themes anyway, given the first commit listed above.
>
>  Meanwhile, building gtk-window-decorator without metacity 
>support at
>  all was broken accidently in changes to support metacity 3.20 by 
>using
>  metacity version selectors but not checking to see if Metacity 
>support
>  is being used at all.
>
>  I build compiz for use in Debian Unstable (and offer my builds 
>for
>  public use) so I saw this a couple days ago. All I could so was 
>switch
>  decorators to Emerald (which compiz-reloaded has ported to GTK3) 
>and
>  use the Emerald pixmap engine to write an Emerald theme matched 
>to my
>  metacity theme.  Ubuntu MATE may have to do the same post-Yakkety
>  unless Ubuntu either pins Metacity, gets a 3.22 port to work and 
>finds
>  it handles metacity themes, or modified gtk-window-decorator to 
>read
>  metacity themes directly without using libmetacity.
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/compiz/+bug/1629749/+subscriptions