gnuplot-beta

Re: maximing/resizing multiple x11: change of palette

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

> So, say two plots are created and by default they are both set to
> "plot->cmap = cmap".  Then whenever PaletteMake() is run on the colormap
> for one of the plots, it is effectively changing the color map for the
> other.  So, that is why I'm saying that somewhere along the way upon the
> creation of a plots color map, it must *duplicate* the default palette,
> i.e., malloc an equal amount of memory as "cmap" and then use memcpy().
>  That is, if one wants color maps to be preserved in plots.  I assume
> that when the palette is changed at gnuplot's command line, that change
> is supposed to apply to the default palette as well as the current
> plot's palette.

Yes, every x11 windows should have its own copy of the palette. When there
is a new (re)plot, x11 should copy the current gnuplot palette into palette
of the active window, and use that.

Can you please implement this?

---
PM

Re: maximing/resizing multiple x11: change of palette

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

Petr Mikulik wrote:

>Yes, every x11 windows should have its own copy of the palette. When there
>is a new (re)plot, x11 should copy the current gnuplot palette into palette
>of the active window, and use that.
>
>Can you please implement this?
>

Petr, I'll take a look this weekend.

I don't like hacking stuff, and this may take some consideration.  I'm 
wondering how this should be structured, and whether we should be 
conservative with palette usage in order to not consume too much memory. 
 Are palettes memory consumers?  If so, it might be wise to not save a 
color map with every plot.  That is, say there is a fairly large 
palette, and then someone creates twenty plots.  If all those plots have 
a similar palette, it may be an inefficient use of memory.

Rather, it might be wise to have a linked-list of palettes.  Whenever a 
new palette is created, it is put in the linked list.  Then, when a 
palette is changed at the gnuplot command line, gplt_x11.c will search 
through the plot list and see if any of the plots is using the old 
palette.  If not, that color map can be discarded from the list.

It sounds unnecessarily tedious, but it really does seem like the thing 
to do, and it actually might simplify the various uses of XAllocColor 
and XFreeColors.

Dan

Re: maximing/resizing multiple x11: change of palette

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

This is an old bug (August 2004, see below). What do you think nowadays 
about fixing it?

Petr

***

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.

Try this script:


set pm3d map

set term x11 10
set title '10 gray levels'
set palette gray
set palette maxcolors 10
splot x*x

set term x11 2
set title '2 colors'
set palette color
set palette maxcolors 2
splot x


Now, maximize or resize window #10 by mouse => it will change from gray map
with 10 gray levels to color map with 2 colors.




>> Yes, every x11 windows should have its own copy of the palette. When there
>> is a new (re)plot, x11 should copy the current gnuplot palette into palette
>> of the active window, and use that.
>
> I don't like hacking stuff, and this may take some consideration.  I'm 
> wondering how this should be structured, and whether we should be 
> conservative with palette usage in order to not consume too much memory. Are 
> palettes memory consumers?  If so, it might be wise to not save a color map 
> with every plot.  That is, say there is a fairly large palette, and then 
> someone creates twenty plots.  If all those plots have a similar palette, it 
> may be an inefficient use of memory.
>
> Rather, it might be wise to have a linked-list of palettes.  Whenever a new 
> palette is created, it is put in the linked list.  Then, when a palette is 
> changed at the gnuplot command line, gplt_x11.c will search through the plot 
> list and see if any of the plots is using the old palette.  If not, that 
> color map can be discarded from the list.
>
> It sounds unnecessarily tedious, but it really does seem like the thing to 
> do, and it actually might simplify the various uses of XAllocColor and 
> XFreeColors.

Re: maximing/resizing multiple x11: change of palette

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

Petr Mikulik wrote:
> This is an old bug (August 2004, see below). What do you think nowadays 
> about fixing it?

That bug is still in there?  I thought I had programmed that just as I had suggested below, i.e., a linked list of colormap.  (That is, don't duplicate colormaps for each plot unless it actually changes.)  Maybe that patch is still floating around somewhere.

I've really been set back by some computer things (got back from long break and now can't communicate IP address to/from ISP).  There are a number of gnuplot things I've been meaning to get to soon.

Dan


> 
> Petr
> 
> ***
> 
> 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.
> 
> Try this script:
> 
> 
> set pm3d map
> 
> set term x11 10
> set title '10 gray levels'
> set palette gray
> set palette maxcolors 10
> splot x*x
> 
> set term x11 2
> set title '2 colors'
> set palette color
> set palette maxcolors 2
> splot x
> 
> 
> Now, maximize or resize window #10 by mouse => it will change from gray map
> with 10 gray levels to color map with 2 colors.
> 
> 
> 
> 
>>> Yes, every x11 windows should have its own copy of the palette. When 
>>> there
>>> is a new (re)plot, x11 should copy the current gnuplot palette into 
>>> palette
>>> of the active window, and use that.
>>
>>
>> I don't like hacking stuff, and this may take some consideration.  I'm 
>> wondering how this should be structured, and whether we should be 
>> conservative with palette usage in order to not consume too much 
>> memory. Are palettes memory consumers?  If so, it might be wise to not 
>> save a color map with every plot.  That is, say there is a fairly 
>> large palette, and then someone creates twenty plots.  If all those 
>> plots have a similar palette, it may be an inefficient use of memory.
>>
>> Rather, it might be wise to have a linked-list of palettes.  Whenever 
>> a new palette is created, it is put in the linked list.  Then, when a 
>> palette is changed at the gnuplot command line, gplt_x11.c will search 
>> through the plot list and see if any of the plots is using the old 
>> palette.  If not, that color map can be discarded from the list.
>>
>> It sounds unnecessarily tedious, but it really does seem like the 
>> thing to do, and it actually might simplify the various uses of 
>> XAllocColor and XFreeColors.
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. 
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


-- 

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/

Re: maximing/resizing multiple x11: change of palette

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

>> This is an old bug (August 2004, see below). What do you think nowadays
>> about fixing it?
>
> That bug is still in there?  I thought I had programmed that just as I had
> suggested below, i.e., a linked list of colormap.  (That is, don't
> duplicate colormaps for each plot unless it actually changes.)  Maybe that
> patch is still floating around somewhere.

Yes, the bug is still present.

---
PM

Re: maximing/resizing multiple x11: change of palette

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

Petr Mikulik wrote:
> This is an old bug (August 2004, see below). What do you think nowadays 
> about fixing it?

Petr,

Attached is a freshened version of the patch for the bug fix.  Give it a try and if you think it solves the problem please consider moving into CVS.

As a reminder to others, we had a big discussion about this bug.  (Go back to about Sep  9, 2004.)  In addition to the initial problem Petr found, I think this patch also has a bug fix for what I thought was a memory leak.  It also rid that difficult to decipher code with "recursive" in it.

In summary, it is a linked list of color maps separate from the linked list for X11 plots.  (Hey, I like linked lists; what can I say?)  Basically, whenever a new palette (i.e., different than any other already in the list) comes over the link it is placed in the list.  Whenever a figure is destroyed and the associated palette is not used by a different plot, that palette is discarded from the list.

Dan

 
> ***
> 
> 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.
> 
> Try this script:
> 
> 
> set pm3d map
> 
> set term x11 10
> set title '10 gray levels'
> set palette gray
> set palette maxcolors 10
> splot x*x
> 
> set term x11 2
> set title '2 colors'
> set palette color
> set palette maxcolors 2
> splot x
> 
> 
> Now, maximize or resize window #10 by mouse => it will change from gray map
> with 10 gray levels to color map with 2 colors.
> 
> 
> 
> 
>>> Yes, every x11 windows should have its own copy of the palette. When 
>>> there
>>> is a new (re)plot, x11 should copy the current gnuplot palette into 
>>> palette
>>> of the active window, and use that.
>>
>>
>> I don't like hacking stuff, and this may take some consideration.  I'm 
>> wondering how this should be structured, and whether we should be 
>> conservative with palette usage in order to not consume too much 
>> memory. Are palettes memory consumers?  If so, it might be wise to not 
>> save a color map with every plot.  That is, say there is a fairly 
>> large palette, and then someone creates twenty plots.  If all those 
>> plots have a similar palette, it may be an inefficient use of memory.
>>
>> Rather, it might be wise to have a linked-list of palettes.  Whenever 
>> a new palette is created, it is put in the linked list.  Then, when a 
>> palette is changed at the gnuplot command line, gplt_x11.c will search 
>> through the plot list and see if any of the plots is using the old 
>> palette.  If not, that color map can be discarded from the list.
>>
>> It sounds unnecessarily tedious, but it really does seem like the 
>> thing to do, and it actually might simplify the various uses of 
>> XAllocColor and XFreeColors.
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. 
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


-- 

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/

Re: maximing/resizing multiple x11: change of palette

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

Yes, your patch fixes the bug, so I wish to move it to cvs.

---
PM