Subject: RE: slow X update
To: Chuck Cranor <chuck@maria.wustl.edu>
From: Tim Rightnour <root@garbled.net>
List: port-i386
Date: 04/01/1998 10:32:31
On 01-Apr-98 Chuck Cranor spoke unto us all:
# 
# i'm not an X expert, but from looking at the fvwm2 source code the only
# thing that looks suspect is the calls to XAllocColor() in add_window.c.
# the man page for XAllocColor claims there is an XFreeColors() function.
# I only see one call to that function and it is in builtin's FreeButtonFace().
# 
# when is it appropriate to call XFreeColors?   if you XAllocColor when
# you add a new window, should you XFreeColors when the window goes away?
# does anyone know?
# 

XAllocColor grabs the "closest match" from the color map, if at all possible,
otherwise it creats a read-only color.   If you have allocated a ton of
read-only colors, other applications will not be able to share those colors
with yours. (meaning potentially you will have two of the same color on your
map)  XFreeColor disassociates the mapping on a read-write color cell, so
another application is free to use that cell for its own mapping.

>From the Oriely Xlib manual:
Since all the colorcells an application allocates are freed when the
application exits, this routine is needed only when an application is finished
with cells before it exits.

My understaning of the Xserver is, that the cell maps are pre-allocated in
memory..  changing the colors they contain is not going to change the memory
use of the application or the server at all.  It may not be as friendly to
other X apps.. but it's not a memory leak. (unfriendly in the context of a WM,
which never really exits)

---
Tim Rightnour    -  root@garbled.net
http://www.zynetwc.com/~garbled/garbled.html