Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!mcsun!hp4nl!alchemy!markov
From: markov@cs.ruu.nl (Mark Overmars)
Newsgroups: comp.sys.sgi
Subject: Re: getmcolor() on VGX's
Message-ID: <1991Jun26.135917.16524@cs.ruu.nl>
Date: 26 Jun 91 13:59:17 GMT
Article-I.D.: cs.1991Jun26.135917.16524
References: <1991Jun24.142930.29853@ux1.cso.uiuc.edu> <1991Jun25.191922.7763@odin.corp.sgi.com>
Organization: Utrecht University, Dept. of Computer Science
Lines: 53

In <1991Jun25.191922.7763@odin.corp.sgi.com> fouts@teehee.dallas.sgi.com (Chris Fouts) writes:

>
>If you try to read the colormap from an RGB window on a VGX it will fail (after
>all, it's an RGB window--not a colormap window).  You can get around this with
>something like (untested code follows :^):
>
> (stuff deleted)
>
>This should work since the map_id window is a colormap window (even though
>it isn't mapped).  Of course, you'll take a slight performance hit with the
>extra calls.
>

Well, I had this same problem. I first solved it this way. The performance
penalty is tremendous. So better don't do it this way. The problems seems to
be the winset() calls that are expensive.

>Alternatively, you could write your own routines that store the map color
>values in your own local table, and reference the colors from that.
>

This is indeed the easiest to do. The following piece of code might be what
you want for this:

short fl_red[4096], fl_green[4096], fl_blue[4096];

void fl_init_colormap()
{
  long cmwin;
  int i;
  noport();
  cmwin = winopen("CM");
  for (i=0; i<4096; i++)
    getmcolor(i,&fl_red[i],&fl_green[i],&fl_blue[i]);
  winclose(cmwin);
}

Now define

void fl_color(int col)
{
  RGBcolor(fl_red[col],fl_green[col],fl_blue[col]);
}

and use fl_color() instead of color(). Better change the fl_ things in front
of the calls. You might get problems with Forms otherwise.
(Guess where this came from :-)

Note that this does not give exact colormap behaviour but it does the basic
thing.

Mark Overmars