[329] in Athena User Interface
Re: Graphic design meeting 1pm Monday, Zone
daemon@ATHENA.MIT.EDU (Maciej Stachowiak)
Mon Jul 24 03:42:33 2000
To: Brad Thompson <yak@MIT.EDU>
Cc: aui@MIT.EDU
From: Maciej Stachowiak <mjs@eazel.com>
Date: 24 Jul 2000 00:42:40 -0700
In-Reply-To: Brad Thompson's message of "Sun, 23 Jul 2000 19:37:59 -0400"
Message-Id: <lqn1j86kjz.fsf@pythagoras.eazel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Brad Thompson <yak@MIT.EDU> writes:
> > I'm not sure suche measures are necessary; GdkRGB should provide
> > pretty nice dithering down to a limited color cube on low colordepth
> > displays. It will probably look a lot better than hand-limiting the
> > colors.
>
> The dithering _does_ look lousy when it is used as a background color.
> Regardless, the primary problem is not how the icons look; it's how they
> suck colormap cells from everything else.
>
> At least, that's the assumption. I would feel pretty dumb if there were
> some other part of gnome that's sucking colormap cells and not putting
> them in an obvious place, and we got a graphic designer to redo all the
> icons and we still had the colormap problems.
>
Gtk+ allocates a color cube on initialization, not on demand (if I
understand the code correctly; I'm not a low-level X expert) so I
expect it would suck the same number of colormap cells regardless of
how many your icons actually use. But come to think of it, there are
some parts of GNOME that still use Imlib, which has it's own,
different way of eating the colormap (I think in most sane GNOME
installs, the Imlib pallete is set to match the GdkRGB color cube).
- Maciej
