   The VT,  WinGUI,  and (eventually) SDL2,  SDL1,  and X11 models all
have the ability to support 'full' RGB,  16 million colors.  ncurses
currently supports this with the xterm-direct model,  in which you
get 2^24 colors and can't change them.

   The problem with the ncurses solution is that it breaks existing
palette-based code.  I've found a few people complaining about this.
It's true that one should not blindly assume you'll have a color
palette and can change it,  nor should you assume a particular
color palette. There's no promise of that sort in Curses.  The
can_change_color() function exists for good reason.  (The Linux
console is a good example of a place where you can't change colors.)

   However,  many people (me included) have written code that
assumes that init_color() will actually change the color. I think
a lot of people do.  If somebody complains that it doesn't work in
the Linux console,  we say : "Don't do that."

   Fortunately,  PDCurses has been revised so that it uses the
the existing Curses model  _and_ can access a changeable palette
of 16-million colors,  have 2^20 = 1048576 color pairs, and not
require much code or memory.  (Actually, slightly less.)

   As the 'PDC_default_color' function in 'pdccolor.c' shows,  the
first 256 palette entries are the traditional ones : 8 primary
colors,  8 "intensified" primary colors,  a 6x6x6=216 color cube,
and 24 shades of gray.  (Re-defining the first 256 colors would have
broken backward de facto compatibility.)  This is now followed by
2^24 colors,  so COLORS = 2^24 + 2^8.  By default,  palette indices
past 256 have color components

r =  (index - 256) & 0xff
g = ((index - 256) >> 8) & 0xff
b = ((index - 256) >> 16) & 0xff

   All of these colors can be easily computed algorithmically.
Unless a palette entry is deliberately set,  we need allocate no
memory at all,  even though we have a palette of 2^24 + 2^8 colors.
The 'picsview' demo illustrates how this can be done;  color
0xdeadbe, (blue 0xde, green 0xad, blue 0xbe)  for example,  is at
palette index 0xdeadbe + 256 = 0xdeaebe.

   Resetting of palette entries is relatively rare,  especially
because most PDCurses/ncurses programs don't expect more than 256
colors anyway.  'testcurs' resets colors beyond this,  but that's
explicitly to test the above code.  As palette entries are set,
the array of entries ('rgbs' in pdccolor.c) is reallocated to be
the smallest power of two capable of handling all entries.

   The vast majority of programs which either never use color
indices past 256,  or which decide to use them at the default
values, will never cause rgbs[] to be allocated.  If you decide
to use a palette of,  say,  1024 colors,  then fine;  rgbs[] will
be extended to consume 1024 COLOR_PAIR structures (2048 integers,
so 8K of memory with 32-bit integers).  So this doesn't devour a
lot of memory.  (At present,  only 'testcurs' sets colors beyond
256,  in its 'colors beyond 256' section... but this was done
specifically to verify that the code works.)

   If you look in pdcurses/color.c,  you will see that the color
pairs are similarly dynamically reallocated when new pairs are
set.  One can have 2^20 = 1048576 color pairs,  consuming 8
MBytes assuming 32-bit ints. But few applications use more than a
few color pairs.  Again, 'testcurs' does so in the same 'colors
beyond 256' section.  I have run 'picsview' full-screen with a
tiny font to get it to allocate over 100K color pairs... indeed,
that sort of "picture drawing" is the only case I can think of
where one might use really large numbers of colors.
