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