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.