drb@eecg.toronto.edu (David R. Blythe) (01/19/91)
I am working on a interactive color map editor which likes to update the entire subset of the color map being edited very rapidly. (e.g. when the frequency or phase of a sinusoid is modified). I am finding mapcolor() to be prohibitively slow when updating 2000 or 3000 color table entries one at a time (it is acceptable when doing only a few hundred entries). Rather than trying to find some way to update the whole colormap less frequently, I was hoping to find a faster way to update large portions of the map (i.e. a gl routine to update a contiguous subrange of the color table - even X has that :-). Is there any undocumented gl_xxx() routine that already does that, or perhaps someone at SGI could be convinced to add such a routine in a future release? drb@clsc.utoronto.ca
lutherk@fiesta.esd.sgi.com (Luther Kitahata) (01/23/91)
In article <1991Jan19.024229.4007@jarvis.csri.toronto.edu>, drb@eecg.toronto.edu (David R. Blythe) writes: |> I am working on a interactive color map editor which likes to update the entire |> subset of the color map being edited very rapidly. (e.g. when the frequency or |> phase of a sinusoid is modified). I am finding mapcolor() to be prohibitively |> slow when updating 2000 or 3000 color table entries one at a time (it is |> acceptable when doing only a few hundred entries). Rather than trying to find |> some way to update the whole colormap less frequently, I was hoping to find a |> faster way to update large portions of the map (i.e. a gl routine to update a |> contiguous subrange of the color table - even X has that :-). Is there any |> undocumented gl_xxx() routine that already does that, or perhaps someone at SGI |> could be convinced to add such a routine in a future release? |> |> drb@clsc.utoronto.ca Unfortunately the speed you are getting is probably as fast as you are going to get. The bottleneck is the speed of the hardware and the fact that the colormap can only be loaded during the montor's vertical retrace. That doesn't mean that your program waits around for vertical retrace for every mapcolor() call, these calls get buffered. But the hardware can't load that many entries in a single vertical retrace so they are spread out over multiple vertical retraces. The speed also depends on the system you are running on. What system are you using? -- Luther Kitahata lutherk@sgi.com ...!{adobe,ames,decwrl,pyramid,ucbvax}!sgi!lutherk