Ethan Merritt wrote:
> On Wednesday 14 June 2006 12:53 pm, you wrote:
>
>>Oh, it would be nice to speed up the palette assignment. Something
>>just isn't right with those demos that use pm3d; takes forever,
>>computer speaking.
>
>
> [shrug] I doubt that it matters for any real-world case.
> But if you want to figure out where the time is going, I think
> you had best start profiling the executable.
Well, the real issue is the reallocating of the palette unnecessarily. I think we fixed this for the mouse redraw, but there are some loose ends.
The problem is these make_palette()'s scattered throughout whenever there is a plot element that needs the palette, e.g.
can_pm3d = is_plot_with_palette() && !make_palette()
if (make_palette() || !term->set_color) {
All that really should be here is something called "valid_palette()", i.e.,
can_pm3d = is_plot_with_palette() && valid_palette()
if (valid_palette() || !term->set_color) {
I still contend that the only time that make_palette() should be done in the core is when
1) a "set palette" is explicitly commanded
2) whenever a "set term" is done (because the palette could have changed a lot while "connected" with a different terminal)
Now, if a "set term x11" is inherent in initialization then there is no need to explicitly initialize the palette.
When "make_palette()" is done, a variable should be set for which
int valid_palette(void)
{
return palette_set_successfully;
}
can be used.
If a particular terminal needs to keep reissuing the palette (as we've concluded that the PostScript term should do for proper post-usage in viewers) then that is the terminal drivers responsibility.
Dan
--
Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/
|
