Subject: Colorlimiting

From: Dan Espen <[email-masked]>
Date: Fri, 09 Apr 1999 11:20:08 -0400

I'm still not  happy with the  current colorlimit logic being applied.
Here is the basis for the current limit:

 * The ColorLimit command is  ignored if the  user has no reason to limit
 * color.  This is so the   same configuration will work on  colorlimited
 * and   non-colorlimited  displays  without    resorting   to using    a
 * preprocessor.
 *
 * Lets assume  the display is  no more  than  2000x1000 pixels. Ie.  the
 * display can display no more than 2,000,000 million  pixels at once.  A
 * display depth of 21 will display 2  million colors at once.  Hence the
 * logic below.

I can  refine  this by using  the  screen dimensions to  get the total
pixels instead of 2000x1000.  But the idea that each pixel will have a
unique color is  flawed.  Also  all the xpms  I've  ever seen use  256
colors or less.

What I would like is for the system that I currently have access to
(1600x1200, 65K colors) to disable Colorlimiting.  Any suggestions on
a better algorithm for this?

Right now, I lack any sort of tool that will work with a 16 bit display
that will tell me how many colors are in use.  Maybe I should hack up
"colormap" to get some kind of baseline numbers.

Other  than that, has  anyone with a  16 bit  display  ever run out of
colors?

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214             E-mail: [email-masked]
Piscataway, NJ 08854                       Phone: (732) 699-5570
--
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: Tomas Ogren <[email-masked]>
Date: Fri, 9 Apr 1999 18:10:45 +0200

> Here is the basis for the current limit:
[...]
> "colormap" to get some kind of baseline numbers.

That's because you have a static palette, you don't alloc any
colors/modify colormaps, you just use them.

> Other  than that, has  anyone with a  16 bit  display  ever run out of

Only PseudoColor displays runs out of colors... 16 bit displays are
usually (99.999%) TrueColor.. Same for 15 bit.. I'd say disable the
colorlimiting if bpp >= 15 ...

One has to think about the case with mixed visuals tho (I haven't had
time to investigate the recent visual stuff implemented), like default
visual 8bpp but possibility of 24bpp...

/Tomas
-- 
Tomas Ögren, [email-masked], http://www.ing.umu.se/~stric/
|- Student of Computer Science at the University of Umeå
`- Sysadmin at {cs,ing,acc}.umu.se
--
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: Fri, 09 Apr 1999 17:27:48 +0100

> unique color is  flawed.  Also  all the xpms  I've  ever seen use  256

I don't think using the screen size is going to give anything useful
since windows can overlap (and be iconified), you could have thousands
of windows each with a unique colour per pixel.

> a better algorithm for this?
Somewhere in X.h or Xlib.h is a bit of blurb about visual types. I think
it says that if the visual class is odd it's a static type and if it's
even it is one you allocate colours out of. You could use that to
disable ColorLimit on static displays.  For non-static displays you
could use the depth to decide what to do with ColorLimit.

Cheers,
Tim.

---

From: Johan Bengtsson <[email-masked]>
Date: Fri, 9 Apr 1999 18:30:37 +0200 (CEST)

> a better algorithm for this?

Personally I would argue for a solution where the descision is based
mainly on the class of the used visual. If the X-server already has
decided on a static set of colors that we are allowed to use, there
is no point for us to try to save slots in the colormap for later use.
Probably this should be combined with a test for visuals with
ridiciously large writeable colormaps.

I have attached a patch implements this.

> Other  than that, has  anyone with a  16 bit  display  ever run out of

The 16 bit displays I have been using have been TrueColor. 

	/ Johan

---

From: Dan Espen <[email-masked]>
Date: Fri, 09 Apr 1999 12:50:49 -0400

> I have attached a patch implements this.

Thanks!

I'll apply this sometime soon.