gnuplot-beta — Developers and beta testers of new gnuplot code

Re: maximing/resizing multiple x11: change of palette

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 29 September 2004 11:17 am, Daniel J Sebald wrote:
> Aha.  It's 'world2.dem'.  I started gnuplot afresh, ran 'animate.dem' 
> (green and red surfaces), ran 'world2.dem', typed 'reset', reran 
> 'animate.dem' (only red this time).

very strange. OK, that's definitely a bug I did not catch.
I have no thoughts on it at the moment, but I hope it will come to
me eventually.

> Also, I just 
> ran 'world2.dem' in X11 and the labels appear in the first plot, do not 
> appear in the second plot (which may be the way it is supposed to be)

This makes no sense to me. I cannot reproduce it here.
The whole point of the demo was to show that hidden line removal
now works for labels too, but you say you don't get any labels.
What happens if you replace that     splot ... font ",7"
spec with    splot ... font "Helvetica,7" instead?

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: maximing/resizing multiple x11: change of palette

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

Daniel J Sebald wrote:

> Aha.  It's 'world2.dem'.  I started gnuplot afresh, ran 'animate.dem' 
> (green and red surfaces), ran 'world2.dem', typed 'reset', reran 
> 'animate.dem' (only red this time).


Speaking of 'world2.dem', spinning around the label-free globe on its 
axis would be a prime candidate for the animate demo.

Dan

Re: maximing/resizing multiple x11: change of palette

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

Petr Mikulik wrote:

>>PS:  Here are some other problems with CVS:
>>
>>1)  The color scheme for X11 'all.dem' isn't the same as it once was.
>> (Or perhaps the whole of all demos has been changed.)  I went back and
>>compared against a version from a couple months ago.  There used to be
>>some hidden line demos where some portions of the 3D surface were green
>>and some red.  (A whole bunch of them.)  Now they are all red the whole
>>way through.  Perhaps hidden lines isn't working properly.
>>    
>>
>
>I have a feeling it works for me. There are both red lines and green lines.
>(Can you compare your X11 to e.g. postscript output?)
>
>  
>
>>The plot titled '"fence plot" using separate parametric surfaces' has a
>>noticeably different color scheme than the old CVS X11.
>>    
>>
>
>I have compared this plot to that of gnuplot from June 3, and it is the
>same.
>
>  
>
>>2)  postscript output has the same problem with two sides of a 3D
>>surface both being red.  (So maybe it isn't X11 with the problem.)
>>    
>>
>
>Aha, you did so.
>
>For me: load 'hidden.dem', plots nb. 3 to 7, have both red and green lines.
>You cann't see it?
>It looks the same if loaded from 'all.dem', or in its own.
>

(CVS just updated, someone must be working on this.)

To quote a Split Enz tune, "I see red, I see red, I see red!"...  but I 
only see it when running 'hidden.dem' and other such demos from 
'all.dem'.  After 'all.dem' and a 'reset', running 'hidden.dem' 
individually stills stays all red.

>>3) In PostScript, the plot two plots after the one titled "Plot 'file'
>>with vectors <arrowstyle>" and all plots after don't appear.  When
>>running 'all.dem', gnuplot hits that plot and then instead of sending
>>PostScript code to the file all of a sudden it starts sending it to the
>>stdout.
>>    
>>
>
>And PDF stops any more writing.
>
>Here is the offending code in vector.dem:
>
>print "Now create a file with equipotential lines"
>pause -1 "Hit return to continue"
>set term push
>set term table
>set out "equipo2.dat"
>rep
>set out
>set term pop
>
>
>=> it resets output!
>
>Try
>	grep "set out" *.dem
>
>I don't see any easy workaround ... we will probably need new command
>	"save output"
>because the output is not normally saved.
>

So _that's_ why it wasn't in all.dem.  I should have thought of that.

>>4) Running 'all.dem' in pdf terminal results in
>>
>>PDFlib I/O error: Resource configuration file 'pdflib.upr' not found
>>    
>>
>
>I don't have this error.
>
>However, I can see a crash here:
>
>gnuplot> load 'world2.dem'
>PDFlib exception (fatal): [2516] PDF_findfont: Metrics data for font '7' not found
>
>The offending line is:
>plot ... with labels notitle point pt 6 lw .1 left offset 1,0 font ",7"
>  
>

Ah, yes.  I forgot that one.  The labels in 'world2.dem' do not appear 
in 'postscript', causing an error message in ghostview.  Also, I just 
ran 'world2.dem' in X11 and the labels appear in the first plot, do not 
appear in the second plot (which may be the way it is supposed to be), 
but then running 'world2.dem' again, there are no labels even in the 
first plot.  Typing 'reset' and rerunning fixes this and the labels 
appear again.

Aha.  It's 'world2.dem'.  I started gnuplot afresh, ran 'animate.dem' 
(green and red surfaces), ran 'world2.dem', typed 'reset', reran 
'animate.dem' (only red this time).

Dan

Re: maximing/resizing multiple x11: change of palette

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

Petr Mikulik wrote:

>We are back to the complain that the ascii-piped X11 is horribly slow.
>Binary transfer (aka OS/2's pm.trm) would boost the performance.
>

Yes.

>I never used palette larger than 256. Usually 100. Note that Octave's
>default value is 64 -- try:  size(gray)
>

Well, that's certainly not a problem.

>I don't know whether Octave users treat "truecolor" photographs, where you
>need more colors.
>

I'm guessing usually 8 bits.  But probably there will be users who have 
images stored in higher resolution than needed, yet will want the large 
palette even though it's superfluous.  Wait to see if someone complains.

Dan

problems revealed by new demos [was Re: maximing/resizing multiple x11: change of palette]

[Ethan M. <merritt@u.washington.edu>]

> > PS:  Here are some other problems with CVS:
> 
> > 3) In PostScript, the plot two plots after the one titled "Plot 'file'
> > with vectors <arrowstyle>" and all plots after don't appear.  When
> > running 'all.dem', gnuplot hits that plot and then instead of sending
> > PostScript code to the file all of a sudden it starts sending it to the
> > stdout.
> 
> And PDF stops any more writing.

Well, that explains why vector.dem was not previously included
in all.dem.   I couldn't remember why that was, and it checked out
OK with x11, but obviously I should have tested more terminal types.
I'll remove it from all.dem again, but probably we should try to
fix the underlying problem.

> Here is the offending code in vector.dem:
> 
> print "Now create a file with equipotential lines"
> pause -1 "Hit return to continue"
> set term push
> set term table
> set out "equipo2.dat"
> rep
> set out
> set term pop
> 
> => it resets output!
> 
> I don't see any easy workaround ... we will probably need new command
> 	"save output"
> because the output is not normally saved.

I can see some other possibilities, but none are obviously
the correct thing to do:

'set term table' could take an optional file name,
leaving the value of "set output" unchanged.
	show output
		output is set to "original"
	set term push
	set term table "equipo2.dat"
	replot
	set term pop
	show output
		output is set to "original"

'set term push' could push the value of output, and
'set term pop' could restore it.  That makes a lot of sense,
but I suppose it could break existing scripts.


> > 4) Running 'all.dem' in pdf terminal results in
> >
> > PDFlib I/O error: Resource configuration file 'pdflib.upr' not found

That's not a gnuplot error.
That's a system configuration problem, specifically an incomplete
installation of pdflib.  pdflib wants that file to be
in some specific search path, and complains if it's not there.


> gnuplot> load 'world2.dem'
> PDFlib exception (fatal): [2516] PDF_findfont: Metrics data for font '7' not found
> 
> The offending line is:
> plot ... with labels notitle point pt 6 lw .1 left offset 1,0 font ",7"
> 
> Ethan, can you please fix it?

That's triggered by the new demo file world2.dem, but it looks like
the underlying problem is that pdf.trm does not interpret font specs
the same way that post.trm and other drivers do.  I'll have a look at that. 


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: maximing/resizing multiple x11: change of palette

[Petr M. <mi...@ph...>]

> Somehow I managed to get time to show up...  I can hazard a guess at where
> all the extra CPU time is going, most likely converting ascii characters
> to a double value, based upon the fact that rgb1_from_gray() constitutes
> 100% in the second example and 0% in the first example.  (If I trust the
> numbers I'm seeing, that is... why would cumulative seconds be so small if
> the command takes 80 seconds to run?  Could it be that X is the one really
> using the CPU time? Can't be, otherwise there wouldn't be such a drastic
> time difference between these two scenarios.)

We are back to the complain that the ascii-piped X11 is horribly slow.
Binary transfer (aka OS/2's pm.trm) would boost the performance.


> Petr, are large numbers of (custom) palette colors a concern?  That is,
> anything beyound 2^12 levels?

I never used palette larger than 256. Usually 100. Note that Octave's
default value is 64 -- try:  size(gray)

I don't know whether Octave users treat "truecolor" photographs, where you
need more colors.

--
PM

Re: maximing/resizing multiple x11: change of palette

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

Ethan Merritt wrote:

>On Tuesday 28 September 2004 02:38 am, Daniel J Sebald wrote:
>  
>
>>Line 817... OK, I see that.  Let me think it over.  My point is that all 
>>the graphics stuff in response to X events is done by gnuplot_x11 inside 
>>this loop:
>>
>>        do {
>>        XNextEvent(dpy, &xe);
>>        process_event(&xe);
>>        } while (XPending(dpy));
>>
>>Am I understanding correctly that with this configuration the X events 
>>can come at any time, but they are processed in an orderly fashion?
>>    
>>
>
>They are processed in order, yes.  But each pass through the main loop
>will either deal with input from the pipe or with a queue of X events,
>whichever is seen first. The two types of input are asynchronous.
>

That's fine.  So long as none of the X event code changes "current_plot" 
or similar such variables, or modifies X graphics I think we're in good 
shape.


>>I  don't think there are any events initiated by X that can suddenly change 
>>current_plot or current_cmap, which are what the information coming 
>>across the pipe pertains to.
>>    
>>
>
>current_cmap must be something you added, so I don't know 
>how it is handled.  
>
>But unless I am remembering incorrectly, everything else is subject to
>arbitrary change because you can bind any operation at all to a hotkey,
>and the hotkey is recognized and executed as an X event.  
>Isn't that right? This is admittedly perverse, but consider the case
>	bind K "set term x11 7; set palette gray; replot"
>

That is perverse.  But how can this find intermix with what is coming 
across the pipe?  For example, wouldn't it be something like

plot "superslowplot"
<press K while info transferring across pipe, the above bindings get queued>
<plot finishes and returns to command line>
set term x11 7
set palette gray
replot

The X event processing isn't directly changing current_plot (i.e., set 
term x11 7).  It is simply telling gnuplot to change it... eventually.

>Now suppose I hit K in a plot window while your code is reading
>from the pipe. Will your code survive have the terminal closed,
>re-opened and replotted with a different palette in mid-stream?
>

It should do reasonably well, meaning that it won't crash.  That is, if 
there are some commands lost you can't expect the plot to make any 
sense.  But if a replot is done, that will resend all the plot 
information and it should be fine.

>>We'll just see how it behaves and if we can break it.
>>    
>>
>
>Race conditions can be very hard to find by trail and error.
>You really need to think about these issues while designing
>the code in the first place.
>

I know.

Dan

PS:  Ethan, is there a command line configure switch to make gnuplot_x11 
work with a profiler?  I see a program called "gprof" that I'd like to 
apply and see what is taking so long in the palette.  I'm not completely 
happy with the speed of the custom palette... and may switch back to 
palettes_differ() vs. cmaps_differ() if I can't resolve that.  Thanks.

Re: maximing/resizing multiple x11: change of palette

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 28 September 2004 02:38 am, Daniel J Sebald wrote:
> Line 817... OK, I see that.  Let me think it over.  My point is that all 
> the graphics stuff in response to X events is done by gnuplot_x11 inside 
> this loop:
> 
>         do {
>         XNextEvent(dpy, &xe);
>         process_event(&xe);
>         } while (XPending(dpy));
> 
> Am I understanding correctly that with this configuration the X events 
> can come at any time, but they are processed in an orderly fashion?

They are processed in order, yes.  But each pass through the main loop
will either deal with input from the pipe or with a queue of X events,
whichever is seen first. The two types of input are asynchronous.

> I  don't think there are any events initiated by X that can suddenly change 
> current_plot or current_cmap, which are what the information coming 
> across the pipe pertains to.

current_cmap must be something you added, so I don't know 
how it is handled.  

But unless I am remembering incorrectly, everything else is subject to
arbitrary change because you can bind any operation at all to a hotkey,
and the hotkey is recognized and executed as an X event.  
Isn't that right? This is admittedly perverse, but consider the case
	bind K "set term x11 7; set palette gray; replot"

Now suppose I hit K in a plot window while your code is reading
from the pipe. Will your code survive have the terminal closed,
re-opened and replotted with a different palette in mid-stream?

> We'll just see how it behaves and if we can break it.

Race conditions can be very hard to find by trail and error.
You really need to think about these issues while designing
the code in the first place.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: maximing/resizing multiple x11: change of palette

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

Daniel J Sebald wrote:

> I've tried some images in Octave, increasing the palette 2^6, 2^7, 
> etc. Around 2^14 gnuplot_x11 *really* slows down.  I'm talking on the 
> scale of minutes.
>
> Could it be that:
>
>          if (XAllocColor(dpy, new_cmap->colormap, &xcolor)) {
>
> is a slow routine and allocating these colors one at a time is very 
> slow?  Is there some way to assign colors all at once?


Actually, that may not be the problem.  I notice that choosing the max 
colors in gnuplot to be 32768 doesn't take too long.  So the difference 
may be that in Octave the palette is custom and the issue is all the 
ASCII encoded palette information going across the gnuplot/gnuplot_x11 
pipe and then read using scanf.  (I'm not sure.)  This could be a little 
annoying when working in Octave, although I don't think images often 
have a resolution much beyond 12 bits.

However, I would say that if it does turn out to be a problem, once the 
colormap is put in X, the window refreshes just fine... so I'm wondering 
if *not* always sending the palette information to gnuplot_x11 would be 
a good thing to do.  I don't see a problem with sending the palette only 
when it should be changed.  I'll put a toe in that camp for now.

Dan

Re: maximing/resizing multiple x11: change of palette

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

Daniel J Sebald wrote:

> OK, I think I have a solid version of the new colormap list scheme.  
> It needs a good cleaning yet, but give it a try.


I've tried some images in Octave, increasing the palette 2^6, 2^7, etc. 
 Around 2^14 gnuplot_x11 *really* slows down.  I'm talking on the scale 
of minutes.

Could it be that:

          if (XAllocColor(dpy, new_cmap->colormap, &xcolor)) {

is a slow routine and allocating these colors one at a time is very 
slow?  Is there some way to assign colors all at once?

Dan

Re: maximing/resizing multiple x11: change of palette

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

OK, I think I have a solid version of the new colormap list scheme.  It 
needs a good cleaning yet, but give it a try.  (The patch is against CVS 
from a day or two ago.)  There are still some comments printed out when 
colormaps are created, deleted, etc.  Watch them to see if they make 
sense, e.g., a color map is removed when it is not unique, or when it is 
no longer needed, etc.

The major change is the PaletteMake() routine.  The "recursion" variable 
is gone, the colormap is built first and then compared (because 
sm_palette is not stored as part of cmap_t), and the comparison is 
against the whole of the colormap list.  So, where there used to be 
palettes_differ() there is now cmaps_differ(), which looks like [if 
someone can find a better way of computing the size of the memory block 
to compare, let me know]:

/*-----------------------------------------------------------------------------
 *   cmaps_differ - Compare two colormaps, return 1 if differ.
 *---------------------------------------------------------------------------*/

static int
cmaps_differ(cmap_t *cmap1, cmap_t *cmap2)
{

    /* First compare non-pointer elements. */
    if ( memcmp(&(cmap1->colors[0]), &(cmap2->colors[0]), 
(long)&(cmap1->pixels)-(long)&(cmap1->colors[0])) )
        return 1;

    /* Now compare pointer elements. */
    if (cmap1->allocated) {
        if (cmap1->pixels && cmap2->pixels) {
            if ( memcmp(cmap1->pixels, cmap2->pixels, 
cmap1->allocated*sizeof(cmap1->pixels[0])) )
                return 1;
        } else
            return 1;
    }

    return 0;  /* They are the same. */

}

I like the use of memcmp [potentially a fast assembly routine if done 
right] versus the individual comparisons inside palettes_differ().

Dan

Re: maximing/resizing multiple x11: change of palette

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

Ethan Merritt wrote:

>On Monday 27 September 2004 03:27 pm, Daniel J Sebald wrote:
>  
>
>>Ethan Merritt wrote:
>>
>>    
>>
>>>I'm a bit worried about races if you mix scheme (a) with the replots
>>>done under scheme (b).  
>>>
>>>      
>>>
>>I thought I saw that the core of gnuplot of x11 looks at events and then 
>>handles them, handles drawing commands, etc.  So, I think the scenarios 
>>you mention above should all complete before a next operation can take 
>>place.
>>    
>>
>
>I don't think so.  The main loop does a select() at line 817 of gplt_x11.c 
>that mixes input from the pipe (line 849) and from X events (line 844).
>I see nothing to stop an X event from slipping in between two successive
>reads from the input pipe.
>

Line 817... OK, I see that.  Let me think it over.  My point is that all 
the graphics stuff in response to X events is done by gnuplot_x11 inside 
this loop:

        do {
        XNextEvent(dpy, &xe);
        process_event(&xe);
        } while (XPending(dpy));

Am I understanding correctly that with this configuration the X events 
can come at any time, but they are processed in an orderly fashion?  I 
don't think there are any events initiated by X that can suddenly change 
current_plot or current_cmap, which are what the information coming 
across the pipe pertains to.

But you are right that something must go awry if, say, a window is 
closed when only half the plot information has been put through a pipe. 
 You probably don't remember, but we did once wonder what should happen 
when the current_plot is closed.  Should we make another plot current? 
 Or just set current_plot to NULL.  We went with setting it to NULL, 
which is probably the more wise thing to do.  The reason is you can 
react accordingly, e.g., open a new plot window (with the 
"most_recent_plot_number", something we talked about a couple weeks 
ago), or do nothing if current_plot is NULL until a new 'G' or 'N' 
command comes along to redo a plot.

I think I'm getting off course here, but my point is that there does 
seem to be graceful behavior for this.


>>That is, gnuplot_x11 is the one actually closing 
>>plots and X windows, somewhere in its event cycle.  The outside error 
>>events are just requesting that gnuplot_x11 close windows, etc.
>>    
>>
>
>Not be relevant to the current point, but that's not true either.
>Yes, if you type "q" or "ctrl-q" then it's gnuplot_x11 that actually closes
>the plot window.  But if you select XKill or some window manager function
>to close the plot window then I think it's already gone by the time gnuplot_x11
>finds out about it.
>

OK, XKill.  I've not investigated, but is the XKill the little box in 
the upper right corner of an X window, with the 'x'?  From what I 
remember, pressing that button is what causes X to call the routine:

ErrorHandler(Display * display, XErrorEvent * error_event)

which queues up a plot to be removed, not too far after gnuplot_x11's X 
processing loop above.  (I'm watching the DEBUG commands in stderr to 
verify this.)  I'm sure there are other ways for X to close a window, 
but until some X-Man (i.e., true superhero) pinpoints other ways, I'm 
not compelled to hunt for them.

I see my window manager has a "kill app" associated with each window. 
 However, that doesn't kill a window, it kills the app that owns the 
window and leaves gnuplot_x11 defunct.

We'll just see how it behaves and if we can break it.

Dan

Re: maximing/resizing multiple x11: change of palette

[Ethan M. <merritt@u.washington.edu>]

On Monday 27 September 2004 03:27 pm, Daniel J Sebald wrote:
> 
> Ethan Merritt wrote:
> 
> >I'm a bit worried about races if you mix scheme (a) with the replots
> >done under scheme (b).  
> >
> I thought I saw that the core of gnuplot of x11 looks at events and then 
> handles them, handles drawing commands, etc.  So, I think the scenarios 
> you mention above should all complete before a next operation can take 
> place.

I don't think so.  The main loop does a select() at line 817 of gplt_x11.c 
that mixes input from the pipe (line 849) and from X events (line 844).
I see nothing to stop an X event from slipping in between two successive
reads from the input pipe.

> That is, gnuplot_x11 is the one actually closing 
> plots and X windows, somewhere in its event cycle.  The outside error 
> events are just requesting that gnuplot_x11 close windows, etc.

Not be relevant to the current point, but that's not true either.
Yes, if you type "q" or "ctrl-q" then it's gnuplot_x11 that actually closes
the plot window.  But if you select XKill or some window manager function
to close the plot window then I think it's already gone by the time gnuplot_x11
finds out about it.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: maximing/resizing multiple x11: change of palette

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

Ethan Merritt wrote:

>On Monday 27 September 2004 02:49 pm, Daniel J Sebald wrote:
>
>  
>
>>>The basic layout of gnuplot_x11 is that commands are read from the input
>>>stream and either
>>>      (a) executed immediately (e.g. "close window #5")
>>>or    (b) stored in a list to be executed every time the current plot is redrawn.
>>>
>>>Why don't you switch gnuplot_x11 over to using scheme (b),
>>>and we can see just how much of a hit we take in execution time.
>>>      
>>>
>>Because I'm almost done with scheme (a)... changing over to scheme (b) 
>>is the same amount of headaches.
>>    
>>
>
>I'm a bit worried about races if you mix scheme (a) with the replots
>done under scheme (b).  
>
>What happens if somebody resizes or otherwise triggers a replot on
>an old window while you're processing a new palette in the main pipe.
>Will that corrupt the new palette forever after?
>
>What if someone closes an old window (the only remaining user of
>a palette) just as you start to get a new copy of that same palette.
>Can you end up with no copies?  Two copies?
>
>Maybe I worry too much.
>

All good questions; very good questions.  I thought this through a bit 
last week before trying changes this past weekend.  It seems to me that 
gnuplot_x11 is the one controling program flow here and that is what 
lessens concern for me.

Recall that I set up the closing of plots from the system level as a 
little queuing system.  That is, gnuplot_x11 is the one actually closing 
plots and X windows, somewhere in its event cycle.  The outside error 
events are just requesting that gnuplot_x11 close windows, etc. in its 
next event cycle.

I thought I saw that the core of gnuplot of x11 looks at events and then 
handles them, handles drawing commands, etc.  So, I think the scenarios 
you mention above should all complete before a next operation can take 
place.

I'll certainly test out these situations.

Dan

Re: maximing/resizing multiple x11: change of palette

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

Daniel J Sebald wrote:

>>
>> Ethan Merritt wrote:
>>
>>> It is strictly necessary for x11.trm to send the palette with each new
>>> plot, because it has no way of knowing which if any of the previous
>>> plots are still active in gnuplot_x11. 
>>
>>
>
> True, sort of.  In the scheme I have in mind, gnuplot_x11 always 
> retains the current_ map, even if there are no plot windows open.  
> Said another way, when a window closes the color map pointer for that 
> window is checked against the color map pointer of all other windows 
> *and* current_map.  If it is not used somewhere else, then the color 
> map is freed. 


The one problem would be if gnuplot_x11 crashes and gnuplot starts up 
another version of it.  If gnuplot doesn't send a palette, out of luck. 
 However, I've not seen gnuplot_x11 crash unexpectedly in a long time. 
 I guess I'm fine with palette being sent all the time.  Just a bit of 
extra testing.

Dan

Re: maximing/resizing multiple x11: change of palette

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

>
> Ethan Merritt wrote:
>
>> It is strictly necessary for x11.trm to send the palette with each new
>> plot, because it has no way of knowing which if any of the previous
>> plots are still active in gnuplot_x11. 
>

True, sort of.  In the scheme I have in mind, gnuplot_x11 always retains 
the current_ map, even if there are no plot windows open.  Said another 
way, when a window closes the color map pointer for that window is 
checked against the color map pointer of all other windows *and* 
current_map.  If it is not used somewhere else, then the color map is freed.

Dan

Re: maximing/resizing multiple x11: change of palette

[Ethan M. <merritt@u.washington.edu>]

On Monday 27 September 2004 02:49 pm, Daniel J Sebald wrote:

> > The basic layout of gnuplot_x11 is that commands are read from the input
> > stream and either
> >       (a) executed immediately (e.g. "close window #5")
> > or    (b) stored in a list to be executed every time the current plot is redrawn.
> >
> >Why don't you switch gnuplot_x11 over to using scheme (b),
> >and we can see just how much of a hit we take in execution time.
> 
> Because I'm almost done with scheme (a)... changing over to scheme (b) 
> is the same amount of headaches.

I'm a bit worried about races if you mix scheme (a) with the replots
done under scheme (b).  

What happens if somebody resizes or otherwise triggers a replot on
an old window while you're processing a new palette in the main pipe.
Will that corrupt the new palette forever after?

What if someone closes an old window (the only remaining user of
a palette) just as you start to get a new copy of that same palette.
Can you end up with no copies?  Two copies?

Maybe I worry too much.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: maximing/resizing multiple x11: change of palette

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

Ethan Merritt wrote:

>On Monday 27 September 2004 02:18 pm, Daniel J Sebald wrote:
>  
>
>>it.  As Ethan pointed out, there are couple schemes:
>>
>>The basic layout of gnuplot_x11 is that commands are read from the input
>>stream and either
>>	(a) executed immediately (e.g. "close window #5")
>>or	(b) stored in a list to be executed every time the current plot is redrawn.
>>
>>
>>In the former case, gnuplot should only be sending over the palette when 
>>it changes.  In the latter, gnuplot should send every time so that it 
>>goes into the plot buffer.  Right now, gnuplot_x11 is set up for (a), 
>>but gnuplot sends the palette every time a plot is done.  That would 
>>prevent gnuplot_x11 from testing every plot if the palette changed. 
>>    
>>
>
>It is strictly necessary for x11.trm to send the palette with each new
>plot, because it has no way of knowing which if any of the previous
>plots are still active in gnuplot_x11.
>
>Why don't you switch gnuplot_x11 over to using scheme (b),
>and we can see just how much of a hit we take in execution time.
>

Because I'm almost done with scheme (a)... changing over to scheme (b) 
is the same amount of headaches.  Saving it in the buffer is easy 
enough, but then have to add the code to handle it when it comes out of 
the buffer, i.e., recolor the window.  Maybe not too bad.  Then there 
are the unforseen things like maybe the palette has to be the first 
thing in the buffer otherwise the plotted elements will first be in one 
color map and then half-way though the plot switch over to another color 
map.

Dan

Re: maximing/resizing multiple x11: change of palette

[Ethan M. <merritt@u.washington.edu>]

On Monday 27 September 2004 02:18 pm, Daniel J Sebald wrote:
> it.  As Ethan pointed out, there are couple schemes:
> 
> The basic layout of gnuplot_x11 is that commands are read from the input
> stream and either
> 	(a) executed immediately (e.g. "close window #5")
> or	(b) stored in a list to be executed every time the current plot is redrawn.
> 
> 
> In the former case, gnuplot should only be sending over the palette when 
> it changes.  In the latter, gnuplot should send every time so that it 
> goes into the plot buffer.  Right now, gnuplot_x11 is set up for (a), 
> but gnuplot sends the palette every time a plot is done.  That would 
> prevent gnuplot_x11 from testing every plot if the palette changed. 

It is strictly necessary for x11.trm to send the palette with each new
plot, because it has no way of knowing which if any of the previous
plots are still active in gnuplot_x11.

Why don't you switch gnuplot_x11 over to using scheme (b),
and we can see just how much of a hit we take in execution time.



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: maximing/resizing multiple x11: change of palette

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

Daniel J Sebald wrote:

> So does it seem worthwhile including inside the above structure an 
> instance of t_sm_palette, so that we may have quick comparisons in the 
> case of palettes that are a color formula as opposed to user-defined 
> gradients?  (Of course, I wouldn't store the gradient colors *and* the 
> color map pixels because that would be real bloat.)  Or should we just 
> stick to what I described previously, and if someone has a lot of 
> varied palettes of very large size visible and is switching back and 
> forth between them they will just have to live with it.


Ah... no need for the extra t_sm_palette.  If searching through a, for 
some reason, long list of color maps, when they differ that should fail 
pretty quickly.  So then the only people with slowed down response would 
be those with... lot's of plot windows open with lots of different color 
maps of large size and the colormaps only differ by the very last entry 
in the pixel[] array.  All other normal users should be fine.

Dan

Re: maximing/resizing multiple x11: change of palette

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

Petr,


Daniel J Sebald wrote:

> My thought was as follows:  PaletteMake creates a cmap structure:
>
>
>
> typedef struct cmap_t {
>    Colormap colormap;
>    unsigned long colors[Ncolors];    /* line colors */
> #ifdef             PM3D
>    unsigned long xorpixel;    /* line colors */
>    int total;
>    int allocated;
>    unsigned long *pixels;    /* pm3d colors */
> #endif
> } cmap_t;


I'm thinking that in the case that a palette comes across the pipe and 
it is different from that of the current_plot, the palette code should 
also search the linked list for a colormap that matches the one sent 
across the pipe.  It doesn't seem too far-fetched to me that someone 
experimenting with color maps would go back and forth between maps a lot 
of times.  The result could be, similar to the previous discussion, the 
same color map stored in memory many, many times.

So does it seem worthwhile including inside the above structure an 
instance of t_sm_palette, so that we may have quick comparisons in the 
case of palettes that are a color formula as opposed to user-defined 
gradients?  (Of course, I wouldn't store the gradient colors *and* the 
color map pixels because that would be real bloat.)  Or should we just 
stick to what I described previously, and if someone has a lot of varied 
palettes of very large size visible and is switching back and forth 
between them they will just have to live with it.

In some sense, for harmony or parsimony, or whatever you want to call 
it, between gnuplot_x11 and gnuplot, the frequency of sending the 
palette over the link should match how often gnuplot_x11 really needs 
it.  As Ethan pointed out, there are couple schemes:

The basic layout of gnuplot_x11 is that commands are read from the input
stream and either
	(a) executed immediately (e.g. "close window #5")
or	(b) stored in a list to be executed every time the current plot is redrawn.


In the former case, gnuplot should only be sending over the palette when 
it changes.  In the latter, gnuplot should send every time so that it 
goes into the plot buffer.  Right now, gnuplot_x11 is set up for (a), 
but gnuplot sends the palette every time a plot is done.  That would 
prevent gnuplot_x11 from testing every plot if the palette changed. 
 Just nit-picking I guess.

Dan

Re: maximing/resizing multiple x11: change of palette

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

I see something I consider a memory leak in the gnuplot_x11 palette. 
 I'm on the downhill side of revamping the MakePalette routine and will 
fix this, so I don't know if it is worth fixing in CVS or 4.0 errata. 
 If you are curious what the problem is, read on...

=========

Considering the case of supplying a gradient or user-defined 
(user-defined is implemented as a special type of gradient) the routine

static void
scan_palette_from_buf( plot_struct *plot )
{
    t_sm_palette tpal;

will scan a user-defined palette from the pipe.  In the case of  "case 
SMPAL_COLOR_MODE_GRADIENT: {" there is a malloc:

    tpal.gradient = (gradient_struct*)
      malloc( tpal.gradient_num * sizeof(gradient_struct) );

but this memory is never freed anywhere and you see above that "tpal" is 
local, hence this information is discarded.

*However*, this memory can't be freed here.  The current CVS version 
insided PaletteMake() of gplt_x11.c keeps a record of the most recent 
palette sent across the pipe.  And inside of there is:

    case SMPAL_COLOR_MODE_GRADIENT:
      sm_palette.gradient_num = tpal->gradient_num;
      sm_palette.gradient = tpal->gradient;

Notice that this doesn't malloc() any memory.  It just keeps a record of 
the memory that was malloc'd in the scan_palette_from_buf() routine 
above.  So, if one were to free the memory in scan_palette_from_buf(), 
this sm_palette.gradient would be a bogus pointer and later when a 
"palettes_differ()" were called, it would crash from accessing invalid 
memory.

The bottom line is that nowhere is memory for an outdated gradient 
palette discarded.  It could be fixed with a few extra mallocs and 
frees, but I don't know if it is worth it seeing as I'm almost done with 
a re-vamping of the palette stuff.

I've verified this leak by running the imagegp.m script in Octave.  The 
script uses a gnuplot user-defined palette.  If I keep plotting the same 
image, the memory consumption for gnuplot_x11 just keeps growing.

Dan

Re: maximing/resizing multiple x11: change of palette

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

Ethan Merritt wrote:

>This may be a stupid question, but is there not  a much more straightforward
>way of handling this?
>
>The basic layout of gnuplot_x11 is that commands are read from the input
>stream and either
>	(a) executed immediately (e.g. "close window #5")
>or	(b) stored in a list to be executed every time the current plot is redrawn.
>
>Right now setting the palette is treated as category (a). That is, the routine
>scan_palette_from_buf() is executed immediately but the information is not
>stored with the plot.
>
>Can't you fix this problem by moving the operation into category (b) instead?
>Just store the stream of palette information as part of the plot, and then 
>execute scan_palette_from_buf() each time the plot is redrawn.
>

Sure.  That is one approach.  Conceptually, that's not too much 
different than saving a cmap structure (as opposed to a pointer) for 
each plot.  The issue with this approach is that if, say, there are 10 
different plots, all with a similar color map and that colormap is 
fairly big, then there are ten instances of the color map.

I know there is this general feeling now days that "memory is cheap", 
but when talking a computer system (as opposed to some specific embedded 
application) I still like to make memory preservation a priority.  Hence 
a linked-list of color maps.

Actually, there really isn't too much extra code for a linked list of 
color maps.  (Although, I think we both agree that X is the one that 
should be handling this if only its TrueColor/DirectColor stuff were 
easier to work with.)

>I don't know what the speed impact of this might be.
>But if it works at all, you could worry later about optimizing it by keeping
>some sort of global flag that tracks the last palette loaded, and skip the
>reload if it hasn't changed.
>

This probably wouldn't work so good with the scheme of saving the color 
map in the plot buffer.  You'd be better off just recoloring the window 
and not worrying about whether changes occurred.  If one does try this, 
then it is back to the same question of how do you know it has changed? 
 If one is switching between plots and has to RecolorWindow(), there 
will be no pointers between which to do comparison because the palette 
information will be somewhere within the plot buffer.  I'm not sure, but 
I think you'd have to search within the other plot's buffer for the 
palette information.

Dan

Re: maximing/resizing multiple x11: change of palette

[Ethan M. <merritt@u.washington.edu>]

This may be a stupid question, but is there not  a much more straightforward
way of handling this?

The basic layout of gnuplot_x11 is that commands are read from the input
stream and either
	(a) executed immediately (e.g. "close window #5")
or	(b) stored in a list to be executed every time the current plot is redrawn.

Right now setting the palette is treated as category (a). That is, the routine
scan_palette_from_buf() is executed immediately but the information is not
stored with the plot.

Can't you fix this problem by moving the operation into category (b) instead?
Just store the stream of palette information as part of the plot, and then 
execute scan_palette_from_buf() each time the plot is redrawn.

I don't know what the speed impact of this might be.
But if it works at all, you could worry later about optimizing it by keeping
some sort of global flag that tracks the last palette loaded, and skip the
reload if it hasn't changed.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

gnuplot QT front end is back

[Primorec <igo...@gm...>]

Hi all

In your FAQ http://www.gnuplot.info/faq/faq.html#SECTION00073000000000000000
you are talking about gnuplot GUI front ends. One of them is "xgfe"
based on QT toolkit.
This front end disappeared from the face of the Earth ... ooops  of
the  internet.
I've stumbled today upon it's 100% replacement.  It is called "qgfe"
and it can be downloaded from here http://www.xm1math.net/qgfe/.

Please replace outdated link 
http://www.tug.org/tex-archive/graphics/gnuplot/contrib
with the new one http://www.xm1math.net/qgfe/.

In other words, please replace  this

\item \texttt{xgfe}: graphical front end using the Qt widgets available at
      \http{www.tug.org/tex-archive/graphics/gnuplot/contrib/}.

with this

\item \texttt{xgfe}: graphical front end using the Qt widgets available at
      \http{www.xm1math.net/qgfe/}

Thanks
Igor