On Wed, 26 Apr 2000, Michael Natterer wrote:
[...]
So the best thing is probably to remove install_cmap from gimprc and
have only a min_colors options.
But don't we have to tell plugins if the Gimp app installed a colormap?
Or can we leave this decision to the plugin's GdkRGB instance?
IMHO, telling the plugins if the Gimp app has installed a colormap
will not help much (as long as our goal is to reduce colormap flashing
between the app and the plugins) because if the app did install a
colormap, you cannot be sure that the plugins will use exactly the
same one. This is even more tricky when the app uses a non-default X
visual, because some plugins do not choose the same visual.
Here is a bit of context: one of the machines on which I test the Gimp
is a Sun box running openwin in a mode that supports both 24 bpp and 8
bpp visuals simultaneously. The default visual (root window) uses
PseudoColor (8 bits with a colormap) but some applications such as the
Gimp, XV or Netscape select the "best" visual for their windows, which
is TrueColor (24 bits). Here are some exceprts from xdpyinfo:
name of display::0.0
version number:11.0
vendor string:Sun Microsystems, Inc.
vendor release number:3600
[...]
screen #0:
dimensions:1280x1024 pixels (361x288 millimeters)
resolution:90x90 dots per inch
depths (3):1, 8, 24
root window id:0x37
depth of root window:8 planes
[...]
number of visuals:16
default visual id: 0x20
visual:
visual id:0x20
class:PseudoColor
depth:8 planes
available colormap entries:256
red, green, blue masks:0x0, 0x0, 0x0
significant bits in color specification:8 bits
[...]
visual:
visual id:0x2d
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
Using a PseudoColor visual (0x20) as the default allows me to run
legacy X applications, while the more recent applications select a
TrueColor visual automatically. So when the Gimp starts, it uses
a 24 bpp visual.
Until recently, there was a problem with some plug-ins such as
"Filters/Map/Map Object" and "Filters/Light Effects/Lighting Effects"
which did not use the same method as the main app for selecting the
visual and colormap. As a result, these plugins were starting with
the PseudoColor visual, which gave some ugly colormap flashing and
reduced the quality of the previews.
Well, unfortunately the problem is even worse with 1.1.20: I just
tried these two plug-ins in order to check if they got better with the
new code, but they crash. Most plugins work fine, but the two
mentioned above crash shortly after opening their window. The crash
seems to happen when they try to display the preview, and generates
the following error:
Gdk-ERROR **: BadMatch (invalid parameter attributes)
serial 653 error_code 8 request_code 72 minor_code 0
I haven't analyzed this in detail yet (so I haven't submitted a bug
report yet) but according to Xproto.h, the request code 72 is the code
for XPutImage. I suspect that these two plugins are now opening their
window with the correct visual, thanks to the changes done by Mitch,
but unfortunately there is some old broken code that creates the
preview with a bit depth taken from the default visual instead of the
current one.
So... Hmmm... All this verbosity was about this: we should not only
ensure that the plugins are using the same colormap as the main app,
but this should also be done for the visual. I don't know if this
info should be transmitted over the wire or if some part of libgimp
should ensure that all plugins make the same choices in the same way,
but it should be consistent.
Side note: IMHO, min_colors is better than install_cmap. But maybe
there could be a problem if some other application allocates or
releases some colors while the Gimp is running: if the number of
available colors is just around the threshold, the plugins could take
different decisions about the colormap depending on when they are
started. That would be a bit strange.
-Raphael
