diff options
author | Jose Antonio Ortega Ruiz <jao@gnu.org> | 2012-09-11 01:54:42 +0200 |
---|---|---|
committer | Jose Antonio Ortega Ruiz <jao@gnu.org> | 2012-09-11 01:54:42 +0200 |
commit | 3e7c8cf1a4cd9ea86fd7d1dce13e305dd09fb6fe (patch) | |
tree | 6bdbb5531b0ea777fd14fded17889083792cf67d /src/Plugins/Locks.hs | |
parent | ba95216a359acea6a8e41e10d279dbaa85561084 (diff) | |
download | xmobar-3e7c8cf1a4cd9ea86fd7d1dce13e305dd09fb6fe.tar.gz xmobar-3e7c8cf1a4cd9ea86fd7d1dce13e305dd09fb6fe.tar.bz2 |
Avoiding X server leaks with XftColor cache
This patch is a first complete solution to the long-standing memory
leak (on the X server side) caused by repeteadly asking the server to
allocate XftColor instances. Despite the fact that we were freeing
them, the server didn't seem to care... this was also happening for
non-Xft Colors, and solved in the same way we'd done here, i.e., by
caching XftColor instances.
And additional complication has been that Graphics.X11.Xft doesn't
export any function to create and retain an XftColor, nor the
necessary datatype constructors to write a compatible version outside
the module (there's no way to construct an XftColor instance to pass
to the other functions in the library). So, i've created my own lite
version of the whole module, until the day it supports XftColor
creation.
Diffstat (limited to 'src/Plugins/Locks.hs')
0 files changed, 0 insertions, 0 deletions