Re: palette test? [Re: patchset #1448674]

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

Ethan A Merritt wrote:

> That makes it all even easier.
> Please test the following trivial patch and see if it solves whatever
> problems you were having.
> Also test for bad interactions with other terminal types.

OK, I've tried it.  Now, this works very well for x11.trm and the redrawing problem.  I think its performance is better than the patch that I created because, not only is there reduced code, there isn't the step of creating the palette and doing an inefficient test.  The memcmp is a much faster routine.  [I would consider verifying that the memcmp alone catches everything because there is a pointer in that structure.  Couldn't it be the case that if a new palette is built its pointer address could somehow be the same as an old palette if somehow the first palette is deleted before the second one is defined?  The contents of the memory could be different but the starting address the same.]

In any case, what I suspected for other terminals with the "further back test" has shown to be the case.  Try the following commands for the PostScript terminal:

  set term postscript color solid
  set output 'test.ps'
  set pm3d
  splot x
  set output

[now look at the file test.ps in a postscript viewer... looks fine]

  set output 'test.ps'
  replot
  set output

[now look at the file test.ps in a postscirpt viewer... doesn't work]

The problem is that the second plot isn't getting the palette information it needs in the file.

I've tried the above with the patch I created and PostScript still works.

I'm not advocating my patch anymore.  Since we've gone this far why don't we consider solving it the appropriate way.  Going back to my email of a few months back:

> 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.)

Ethan has also proposed sending a variable along with the palette

 	TBOOLEAN same_palette_as_before

which we agreed wasn't the most elegant of solutions.

I'd prefer following the above rule to cut down on extra CPU usage.  I know, I know, CPUs today are fast-fast-fast.  But I always prefer good code... my original attempt at this fix was just a patch to avoid hurting anything else.

Dan