On Thu, Jul 18, 2002 at 06:56:12AM -0400, Dan Espen wrote:
> Olivier Chapuis <[EMAIL PROTECTED]> writes:
> > On Wed, Jul 17, 2002 at 01:18:14PM -0400, Dan Espen wrote:
> > > Olivier Chapuis <[EMAIL PROTECTED]> writes:
> > > >
> > > > I've implemented a new color limit method. It goes at follow:
> > > >
> > > > - At startup if color limitation is needed, a color table is
> > > > created (in fact allocated).
> > > > Various color tables are tried. The first (best) color table
> > > > is chosen: given a color table, the code tries to allocate
> > > > all the element of the table, if one allocation fail the
> > > > allocated colors are freed and the next table is tested.
> > > > The color tables contain 256, 216, 128, 64, 32, 16, 8, 2
> > > > colors respectively. The color tables come from imlib2.
> > > ...
> > > > I can run my driver with depth 8, I get the 216 color table
> > > > (and I can enforce color tables 2, 8, 16 but not the others).
> > > > Now I can run fvwm-themes with depth 8 with a not too bad
> > > > result. Gradient are no pretty, but to fix this we should
> > > > implement a kind of dithering for gradient (dithering for
> > > > large pixmap will be good too).
> > >
> > > If Fvwm allocates 216 colors, that leaves 40 for other
> > > purposes. Thats no good.
> > >
> > > I've had to use 8 bit color in the past.
> > >
> > > Any application that takes the approach you have Fvwm taking
> > > ruins the color map for everything else.
> ...
Seems that this depends on the X implementation.
> > So my question is:
> > "How I/you can reproduce a problem with the new method?"
> > (I do not say this is not possible).
>
> In my current setup, I have a background image limited to
> using 48 colors. With FVWM allocating 216 colors and
> 48 colors in the background, that leaves no colors for
> applications.
>
With XFree we can "ruins the color map" with 13 colors (see my answer
to Tim). And in fact the 216 colors are a subset of the 244 colors
given by the server itself, so here the 216 table allocate no new
colors (but this is maybe/probably a coincidence). Note that you can
steel reduce the nbr of color with the "new" (or tmp) method:
env FVWM_COLORLIMIT=16 fvwm.
This is just a problem about default ("old" method use ~60 colors I
think). But I think that the problems is more complex than a number of
colors. You can allocate 13 colors and ruin your colormap and you can
allocate 216 one's without touching to any free one's (and the new
table with 16 colors really allocate more colors than the 216
table). In fact I try to use an other method because I get problems
with the "old" fvwm color table when I use it as is for reducing
colors for png and tinting (work fine with xpm as the xpm lib make a
part of the job). So in fact, if I well understand, what fvwm have to
do is to not allocate new colors if the number of free colors is <=
a given configurable number. I think this possible to implement, but
this is complicated and maybe slow.
> I don't know why you aren't seeing a problem.
>
Because I think that the installed colormap is good and the
apps I use are not broken.
> > The old method reduce colors in the good way only for xpm. Now I
> > think we need to reduce colors for png, tinting and gradient.
>
> I would not expect to be able to use tinting or
> gradients on an 8 bit display.
>
But tinting work pretty well here in depth 8 and without Xrender.
About gradient I am agree, but I think this is because our
method to build gradien is weak. Here a Black to White Vgradient
with two colors:
BBBBBBBBB
BWBWBBBBB
BBBBBWBWB
BBWBWBWBB
BWBWBWBWB
WBWBWBWBW
WWBWBWBWW
WWWWWBWBW
WBWBWWWWW
WWWWWWWWW
> > Moreover, the most important thing concerning colors with a
> > pseudo color visual is that color allocation MUST never fail. I
> > do not see an other method than this color table method.
>
> To make this work, you'd have to change the X server.
>
I think that the method Tim suggest (take the closest color in the
colormap) should work not so bad. The color table method do that in a
certain sens.
Olivier
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
