From: Petr M. <mi...@ph...> - 2004-09-20 09:31:23
|
> >I have just tried the patch, but it was rejected. Don't you have an > >up-to-date version? > > Why would that patch be rejected? I don't think anyone has altered that > bit of code in CVS... In the cvs current version, there is no that piece of code to be patched. Haven't you use some old gplt_x11.c? > if (plot->cmap->allocated < min_colors && !recursion) { > and replace it with the following > if (!recursion) { But that's completely different from the patch you have sent: XFreePixmap(dpy, plot->pixmap); plot->pixmap = None; } + if (plot != current_plot) + RecolorWindow(plot); display(plot); + if (plot != current_plot) + RecolorWindow(current_plot); } } Thus, what's the patch? > That fixes the problem of keeping track of the color map, but it also > results in an incorrect color map. It looks like a tricky bit of code > because it is recursive. I'm not exactly sure why it is recursive, as > opposed to calling a subroutine twice. In fact, I'm looking at some code > there and wondering what in fact it does. Here is the code in question: > > Notice that the second portion of the if/else statement alters two local > variables, previous and unique_colors, and that is all. That's a useless > bit of code, as I see it. I wish there were a short note explaining why > this is recursive, i.e., on the second time through, what portion of the > code is important? I remember from the old times when Johannes was coding "Make Palette" function for X11 (term->makepalette(NULL)), that number of available colors is not known under some visual modes. Then, you have to try to allocate color palette several times until you find the limit. Can this explain the recursion? However, I wonder why this happens -- once the palette is constructed (according to t_sm_palette) and copied into plot->cmap, it should be used in every replot of that window. Petr |