Complete.Org: Mailing Lists: Archives: freeciv-dev: December 2002:
[Freeciv-Dev] Re: (PR#2484) Xaw client colour allocation patch
Home

[Freeciv-Dev] Re: (PR#2484) Xaw client colour allocation patch

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: vasc@xxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2484) Xaw client colour allocation patch
From: "Jason Short via RT" <rt@xxxxxxxxxxxxxx>
Date: Wed, 4 Dec 2002 22:30:42 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Thu, 2002-12-05 at 01:01, Anthony J. Stuckey via RT wrote:
> On Wed, Dec 04, 2002 at 01:41:27AM -0800, Reinier Post via RT wrote:
> > I have to test this.  I think Freeciv must continue to support running
> > in 8 bit mode.

This patch will only make a difference when running in low-color mode. 
Here "low-color" means that the available colors are not enough to
satisfy the tileset.  Our current tilesets don't have too many colors,
so I suspect 8-bit would be plenty for them.

The difference comes in when there are not enough available colors to
satisfy the client.  The old code would use a custom colormap, thus
discarding colors used by other applications and allocating as many
colors as possible.  Once there were no colors left available, the
remaining required colors will just be assigned to the closes existing
color.  The order the colors are assigned in, though, isn't great. 
First the std_colors are assigned - the equivalent of a small color
cube.  Than new colors are assigned as needed while the sprites are
scanned.  When using a high-color-depth tileset on a low-color-depth
display this could mean you end up with just the std_colors plus 240 or
so shades of green.

The new code will assign colors until it runs out, then use a similar
best-match system.  So in some cases when you run out of colors, you may
end up blurring colors unnecessarily (when a private colormap would have
allowed you to allocate all colors).  But in others (like the
240-shades-of-green) you may end up with a much better colormap.  And in
either case you will have avoided the annoying affect of using a
"private" colormap.

It might be possible to use a much more sophisticated/complicated color
assignment system to get better results out of a private colormap.  For
instance, once we run out of colors in the private colormap instead of
blindly using a "best-fit" system we could have the option of
deallocating and stealing another color if it has a better "best-fit"
than we do.  But this is complicated, since it might not be possible to
deallocate the color if it's in use elsewhere.  And I do not know how to
write the code (and I doubt Vasco has the desire to do it).

Anyway, I have not yet tried the two systems in a low-color environment,
but I suspect that the new system gives comparable or better behavior
than the old in most cases.

jason




[Prev in Thread] Current Thread [Next in Thread]