Re: palette allocation during mouse rotation

[Daniel J S. <dan...@ie...>]

Here's a patch for that gnuplot "allocating colors..." redraw problem with rotation.  The princple is as follows:

On the _terminal driver side_ of the pipe is the following test:

/* Only send the palette if it is different from the last palette,
 * one hasn't been sent yet, or if the plot number is different from
 * the plot number the last time the palette was set.
 */

If one thinks through the logic for that, you'll find it avoids flaky behavior on part of the palette, even in multiplot mode.

That keeps gplt_x11.c from having to reconstruct the color tables unless necessary.  The refresh speedup is clearly back to what it once was.

I would add that another part of this equation is that the gnuplot core doesn't need to send the palette so often.  If it followed the formula that it only send the palette when the _terminal_ changes or the palette commands are entered, it would reduce more wasted CPU.  (If some devices need a copy of the palette for every plot, the driver should keep a copy internally.)  Don't want to get into that, however.  (Note the rule would change if developers went the path of the core used plots as objects, Hans' desire.)

[Petr, I added a couple helper functions.  Could you have a look at the following functions and see if you agree everything is copied and/or deleted properly?

/* create on the heap, a copy of a palette */
duplicate_palette(t_sm_palette *p)
/* remove a palette from the heap */
destroy_palette(t_sm_palette *p)
udft_del(udft_entry *p_del)
udft_cpy(udft_entry *dest, udft_entry *src)

They are right next to palettes_differ().  The part that confuses me is how the Afunc, Bfunc, Cfunc are used.  They appear to be linked list elements, but the list pointers don't appear to be assigned anywhere, and I don't understand why (if they are linked-list elements) they would be tacked into a structure somewhere.  So they must be ignored.

/* user-defined function table entry */
typedef struct udft_entry {
    struct udft_entry *next_udf; /* pointer to next udf in linked list */
    char *udf_name;		/* name of this function entry */
    struct at_type *at;		/* pointer to action table to execute */
    char *definition;		/* definition of function as typed */
    t_value dummy_values[MAX_NUM_VAR]; /* current value of dummy variables */
} udft_entry;

I attempted to get the at_type and definition copy right, but it sure gets deep.  I stopped at temp_at().

I didn't use gp_alloc(), but instead malloc() because there was only malloc()s in getcolors.c.

If you know of any functions that already exist that are similar to what I created, let me know.

I copied your original bug report that started the palette stuff so that you may verify your example still works.]

...

OK, so that's one problem down and two to go.  I'll see if I can get to another one next weekend.

Dan


Petr Mikulik wrote:
>     Hello,
> 
> I think the palette should not be touched, only the "set view" numbers. 
> I think it was Johannes who programmed this rotation by mouse without 
> rereading the data.
> 
>   Petr
> 
>> Haven't thought about this, but just want to remind you the rule is to 
>> allocate the palette only if it changes.  Could it be that something 
>> about the palette is being changed on the plot you are generating?  If 
>> so, it isn't a bug as programmed, but we may want to come up with a 
>> scheme of tagging the color map somehow because we are going back and 
>> forth two different ones.  (I actually would prefer such an approach 
>> because testing the whole palette each time a redraw is done to check 
>> for a change is inefficient.)
>>
>>>
>>> From: Petr Mikulik <mi...@ph...>
>>> Date: 2005/11/27 Sun PM 12:04:34 EST
>>> To: Daniel J Sebald <dan...@ie...>
>>> Subject: palette allocation during mouse rotation
>>>
>>>      Hello Daniel,
>>>
>>> I have just tried to type
>>>
>>>      splot x with line palette
>>> or
>>>      set pm3d
>>>      splot x
>>>
>>> and then rotated the plot by mouse. Now, the title bar shows that 
>>> gnuplot is
>>> allocating the color palette all the time. I think it was not the case
>>> before your last patch. Could you please have a look to this issue?
>>>
>>> Thanks, Petr
> 
> 

There is a bug in the color palette treatment in the X11 terminal: when
using multiple X11 terminals, window redraw (requested e.g. by a window
manager) will change its palette.

Try this script:


set pm3d map

set term x11 10
set title '10 gray levels'
set palette gray
set palette maxcolors 10
splot x*x

set term x11 2
set title '2 colors'
set palette color
set palette maxcolors 2
splot x


Now, maximize or resize window #10 by mouse => it will change from gray map
with 10 gray levels to color map with 2 colors.

Is it possible to fix it?

---
PM