| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2633.1 | | STAR::KLEINSORGE | Fred Kleinsorge, VMS Development | Fri Apr 20 1990 11:36 | 6 |
|
Tsk, tsk, tsk. X11 provides no standard or guidelines for "reserving"
the "default" workstation colors. Which colors/indexes (if any) are
used is server implementation dependent -- you cannot count on having
them loaded in any specific location or order.
|
| 2633.2 | Allocate colors from the inherited colormap | OPHION::MIKEY | Mike Yang | Fri Apr 20 1990 15:34 | 11 |
| The correct way to solve this "problem" is to not create your own
application-specific colormap. but to instead use XAllocColorCells to
allocate colormap cells from the inherited colormap that are "free" or
not used by other applications. Using these cells will not affect
existing applications.
If your application can't get enough colormap cells from the inherited
colormap (e.g. XAllocColorCells returns 0 when you give it the number
of cells you want) then you're going to have problems preserving the
colors of existing applications, unless enough of their colors happen to
be the same as the ones your application uses.
|
| 2633.3 | | STAR::KLEINSORGE | Fred Kleinsorge, VMS Development | Fri Apr 20 1990 16:27 | 22 |
| Actually sllocating color cells doesn't "solve" a large set of
colormap requirements, especially for pseudo-color (and any color
mapped) workstations...
For instance, the application might be dealing with stored images.
If the alignment of a contiguous group of color cells isn't just
right, then each pixel in the image must be translated into a "final"
value.
Now, one way to solve the above is to create and install a private
colormap, copy all the old colors to the new map and then locate the
starting base so that it "works" for the image (you can erase the
window to the "base" pixel value and then simply use the image data
with a plane mask to prevent writing pixels outside of the range you've
selected). The only trick is to know which colors to save...
The example can just as easily be other types of drawing, but the image
operation is probably the worst case. It's unfortunate that X11
doesn't have a more sensible way to divide up the physical colormap
into submaps.
|
| 2633.4 | ... | GSRC::WEST | Variables don't, Constants aren't | Mon Apr 23 1990 16:27 | 20 |
|
This is what I like about the VS 3520/40 hardware architecture. It has
four hardware colormaps.
This way, the default colormap is always loaded and you have room for
three more installed colormaps. This has been a big plus for our customer
who is using PHIGS/PEX which creates its own colormap.
No techicolor windows this way...
I've done what has been mentioned in the previous about creating a colormap
and "copying" cells from the default colormap into the newly created colormap
with success.
One thing to remember is that with the advent of OSF/Motif, it is more
color resource intensive, shading, 3D effect, etc, that this sort of
colormap manipulation could cause you problems down the road.
-=> Jim <=-
|
| 2633.5 | | STAR::KLEINSORGE | Fred Kleinsorge, VMS Development | Tue Apr 24 1990 11:35 | 13 |
|
The problem with the Firefox and the multi-visual architecture is
that there is only a single default colormap! To be able to use
the 8-plane pseudo-color visual (for instance) you need to create
a private colormap and install it. Thus you must have EXCLUSIVE
use of the alternate map. If every visual each had it's own default
colormap, then ALL of the alternate/simultanious visuals could be
shared resources.
Not that this is that big a deal on a machine with a Truecolor visual
and a 24-plane direct color visual. Technicolor windows is probably
not a very big concern - it usually can't happen.
|