Re: maximing/resizing multiple x11: change of palette

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

Dave,

If you want to look into this one, let me know.  (Otherwise I can do it 
one of these evenings.)  I can picture in my mind how to do it.  A 
palette pointer needs to be placed in the plot array.  There is going to 
be some alloc() and realloc() for that pointer and the palette when it 
is changed, or in things like prepare_plot().  The one careful detail is 
immediately upon creating the memory for the plot structure itself as 
part of the linked-list of plots, be sure to set the pointer for the 
palette to 0 (!!! much emphasis).  That could also be done in 
prepare_plot() but I advise putting it at the spot where memory is 
created, because doing it in prepare_plot() leaves open the door for 
someone to inadvertently call prepare_plot() and mash a valid palette 
pointer, creating a memory leak.

Dan


Dave Denholm wrote:

>Ethan Merritt <merritt@u.washington.edu> writes:
>
>  
>
>>On Monday 16 August 2004 01:50 am, Petr Mikulik <mi...@ph...> wrote:
>>    
>>
>>>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.
>>>
>>>Is it possible to fix it?
>>>      
>>>
>>I am not very familiar with this, and I may have it wrong.
>>But It looks to me that the PM3D code would have to be re-written.
>>
>>As it is, gnuplot_x11 only maintains two GC (= "Graphics Context")
>>structures. One of these is used for PM3D operations, and the other
>>is used for everything else.   There is not currently any notion of
>>keeping a separate GC for each plot window.  So if you redefine
>>the PM3D GC to use a different palette, it affects all PM3D operations
>>in all windows.
>>
>>I imagine it would be possible to create a new GC for each window,
>>but I am not sure what pitfalls that would expose.
>>
>>    
>>
>
>
>I had a quick look, and decided that the problem was that colors[] is
>global, so that any change will affect all subsequent
>repaints. Including the colors[] in the (gnuplot_x11) plot structure
>may help.
>
>I don't think the single GC is an issue - the values in the GC are
>reset as required.
>
>
>Eg in
>
>/*-----------------------------------------------------------------------------
> *   display - display a stored plot
> *---------------------------------------------------------------------------*/
>
>void
>display(plot)
>plot_struct *plot;
>{
>
>we have
>
>...
>
>    /* loop over accumulated commands from inboard driver */
>    for (n = 0; n < plot->ncommands; n++) {
>
>    ...
>
>	/*   X11_linetype(type) - set line type  */
>	else if (*buffer == 'L') {
>	    sscanf(buffer, "L%4d", &lt);
>	    lt = (lt % 8) + 2;
>	    /* default width is 0 {which X treats as 1} */
>	    width = widths[lt] ? user_width * widths[lt] : user_width;
>	    if (dashes[lt][0]) {
>		type = LineOnOffDash;
>		XSetDashes(dpy, gc, 0, dashes[lt], strlen(dashes[lt]));
>	    } else {
>		type = LineSolid;
>	    }
>	    XSetForeground(dpy, gc, colors[lt + 3]);
>	    XSetLineAttributes(dpy, gc, width, type, CapButt, JoinBevel);
>	}
>
>
>which is updating the Gc foreground colour, but from the global
>colors[] array, which may have changed since the plot was created.
>
>(I also decided that line widths and dashes could suffer from the same
> problem, but couldn't immediately reproduce any problem
>)
>
>
>
>dd
>  
>

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/