Subject: Problems with the new color cache

From: Tim Phipps <[email-masked]>
Date: Mon, 17 Jan 2000 14:30:11 +0000

There's been a report of a core dump with FvwmTheme due to a failing
XFreeColors(). I'm getting the same thing and I think it's due to the
color cache in libs/ColorUtils.c.  FvwmTheme assumes that every call to
GetHilite() will alloc a pixel and it will XFreeColors() that pixel if
it has to change.  The cache does not do an alloc if it finds the same
color (I assume this is the reason for its existence) and so FvwmTheme's
idea of how many times it has alloc()ed a color will not match the
servers.

Fixes:
1) do an alloc each time. This may make the cache pointless.
2) add a reference count to each pixel in the cache. Use a new function
to free pixels that adjusts the reference count and only free()s when it
hits 0. This will mean changing the cache from a fixed size to a list as
you can't just throw old values away.

Cheers,
Tim.

--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 18 Jan 2000 12:06:29 +0100

> idea of how many times it has alloc()ed a color will not match the

Sigh.  I thought we didn't ever free any of the allocated colours
(at least it has been this way in the past).

> 1) do an alloc each time. This may make the cache pointless.

Indeed.

> you can't just throw old values away.

Not so hot either.

Along with the problem that the cache will produce random result on
non default colour maps or if the colour map changes it seems best
to remove the cache completely, at least for now.

Bye

Dominik ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Tue, 18 Jan 2000 10:23:30 +0000

> you can't just throw old values away.

Thinking about this a bit more, if the GetColor routines just used the
cache to shortcut the XParseColor/XQueryColor and did the XAllocColor
always it would fix the problem with FvwmTheme and would still have a
benefit.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 18 Jan 2000 19:00:12 +0100

>...

Thinking more about this I'm now convinced that the patch in
ColorUtils.c was the wrong way to go.  If we want a colour
cache it should replace XAllocColor/XFreeColor/XQueryColor.

BTW, could somebody restore the old ColorUtils.c please?
I won't get around doing this today.

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Wed, 19 Jan 2000 10:11:03 +0000

> cache it should replace XAllocColor/XFreeColor/XQueryColor.
FvwmTheme can be used as a color cache, just replace all your color
definitions with colorsets and all your color requests go away.

> I won't get around doing this today.

I'll do it.

Cheers,
Tim.

---

From: Alex Wallis <[email-masked]>
Date: Thu, 20 Jan 2000 14:05:08 +1030

> definitions with colorsets and all your color requests go away.

I only use FvwmTheme colorsets in my config but....

FvwmTheme: Cause of next X Error.
   Error: 10 (BadAccess)
   Major opcode of failed request:  88 (FreeColors)
   Minor opcode of failed request:  0
   Resource id of failed request:  0x0
 Leaving a core dump now      

is all I get in my X error log.
Consequently, I get no colors at all, except the default
black and grey.  :(

That's using the CVS I d/l'd yesterday.

Alex

---

From: Tim Phipps <[email-masked]>
Date: Fri, 21 Jan 2000 11:03:56 +0000

> Consequently, I get no colors at all, except the default

This is fixed in the current CVS.
Cheers,
Tim.