The X color model defines read/write restrictions both on
color maps and on individual entries in color maps. As of HP-UX
9.05, Starbase will no longer overwrite read-only color maps or
color map entries as defined in the X color model. Starbase will
generate a warning message if the application attempts to overwrite
read-only color map entries. Attempts to write to color map entries
in read-only color maps (color maps in StaticGray, StaticColor or
TrueColor visuals) are silently ignored. Note that this color map
restriction does not apply to the following
device drivers:
Keyboard and Locator Keyboard
Virtual Memory or File Output (for example, SMD,
CGM, and SBV)
Starbase applications that are running in other visuals (GrayScale,
PseudoColor or DirectColor) may generate Starbase warning messages
and will be unable to change the contents of color map entries that
have been allocated as read-only. Most applications will not be
affected. Examples of where applications will and will not be affected
are given in subsequent sections.
For information on various routines found in the sections
"Cases Where Applications Are Not Affected" and "Cases Where Applications
Are Affected," see the Starbase Reference
or the Xlib Reference Manual by O'Reilly
&Associates, Incorporated. Information for utility routines
not found in the previously listed manuals can be found in this
directory[2]:
 |
|
Cases Where Applications Are Not Affected |
|
This section describes situations where applications will
not generate Starbase commands that try to overwrite read/write
restrictions on color maps or individual entries in color maps.
An application that specifies INIT in any gopen() call on a particular
window will not see this condition. This is because a gopen() call with INIT results in the creation
of a color map that is writable and has all writable entries. Even
if multiple gopen()
calls are used on the same window, so long as one with INIT is executed prior to
any attempt to change the color map contents, the application will
be able to change the contents of the color map and will not generate
Starbase warning messages.
An application that does not specify INIT in any gopen() call on a particular
window will not see this condition if no color map exists for that
window. An example of how this can occur is:
A window is created with the xwcreate
command.
A Starbase application is run to that window and
issues a gopen()
call with INIT.
The Starbase application terminates.
At the end of this sequence, the window will have no color
map associated with it. If another Starbase application attempts
to use the window, Starbase will detect that no color map is currently
associated with the window and will create a new writable color
map with all writable entries, even if the application uses a gopen() without INIT.
An application that does not specify INIT in any gopen() call on a particular
window will not see this condition if a writable color map exists
for that window and that writable color map has all writable entries.
Examples of how such a color map could have been created are:
The application calls shade_mode() with INIT specified for that window.
The application calls double_buffer()
with INIT specified
for that window.
The application creates a color map with all writable
entries using XCreateColormap()
with AllocAll
and created the window using XCreateWindow()
with this color map's ID specified in the window attributes parameter.
The application creates a writable color map using
XCreateColormap()
with AllocAll
and associated it with an existing window using XSetWindowColormap().
The application creates the window using one of
the Starbase utility routines: sb_make_window(),
CreateImagePlanesWindow()
or CreateOverlayPlanesWindow().
It then associated a writable color map with it using XSetWindowColormap(), or
made all the color entries of the allocated color map writable using
XAllocColorCells().
The application creates the window using a Motif
Widget with the XmNcolormap
resource specified as a writable color map ID.
The window inherits a writable color map from its
parent. For example, if an application creates a window with a writable
color map using any of the above techniques, a child window will
inherit the parent's writable color map unless the application specifically
allocated another color map for the child window.
Another process that is still active creates the
window and issues a gopen()
call for it with INIT
specified.
Cases Where Applications Are Affected |
|
This section describes situations where applications can generate
Starbase commands that try to overwrite read/write restrictions
on color maps or individual entries in color maps.
An application that did not specify INIT in any gopen() call on a particular
window and does not allocate a writable color map for the window
may see Starbase warnings if the color map entries have not been
otherwise allocated writable. Examples of how this might happen
are:
The application uses a window that
was just created using the xwcreate
command, does not associate a writable color map with it, and does
not specify INIT
when calling gopen()
for the window. The application then attempts to use define_color_table() to change
the color map contents.
The application creates a color map with no writable
entries using XCreateColormap()
with AllocNone,
creates the window using XCreateWindow()
with this color map's ID specified in the window attributes parameter,
and does not specify INIT
when calling gopen()
for the window. The application then attempts to use define_color_table() to change
the color map contents.
The application creates a color map with no writable
entries using XCreateColormap()
with AllocNone,
and associates it with an existing window using XSetWindowColormap(). The
application then attempts to use define_color_table()
to change the color map contents.
The application creates a window using one of the
Starbase utility routines sb_make_window(),
CreateImagePlanesWindow(),
or CreateOverlayPlanesWindow().
It then calls gopen()
without INIT
specified. The application then attempts to use define_color_table() to change
the color map contents.
The window inherits a color map that has no writable
entries from its parent window. The application calls gopen() without INIT, and then attempts to
use define_color_table()
to change the color map contents.
Note that display_enable()
calls on devices without display enable hardware will also generate
color map change requests. The same is true for double_buffer() and dbuffer_switch() calls where
the application is double-buffering with 1, 2, 3 or 4 planes. Just
as with define_color_table()
calls, the application will generate Starbase warning messages and
will fail to change the color map's contents unless the color map
has writable color entries.
Other Considerations for Starbase Color Maps |
|
When applications change color map entries using Xlib calls,
the results of these Xlib color updates will no longer be visible
to Starbase after gopen()
is called. In fact, Starbase may at times overwrite color map entries
with its own internal version of the color map. Any color map modifications
done through Xlib may be lost.
Both Starbase calls and Xlib calls will affect the hardware
color map, but for example, inquires of Starbase color map contents
using the Starbase inquire_color_table()
routine will only reflect color changes made through Starbase calls.
However, inquiries made through Xlib will see changes made by both
Xlib and Starbase.
Some minor differences in color map sharing on CRX-48Z may
be observed as of HP-UX 9.05. In the past, the CRX-48Z attempted
to optimize color map sharing to minimize technicolor effects. These
optimizations are no longer used as of HP-UX 9.05.
Display enable masks cannot be applied to static color maps.
If a color map is created in a static visual (that is, TrueColor,
StaticColor, or StaticGray, which are supported by the X server
as of HP-UX 9.05), a display enable mask cannot be applied to it
using the display_enable()
routine. The reason for this is that display_enable()
is achieved on devices without display enable hardware by color
map changes. Changing the contents of a static color map is not
permitted under the X color model. Starbase will silently ignore
a display_enable()
request when the window has a static color map. Again, this also
applies to double_buffer()
and dbuffer_switch()
calls when the application is attempting to double-buffer with 1,
2, 3, or 4 planes.
Printable version
