Conference bulova::decw_jan-89_to_nov-90

    
    Yes, the firefox can display from any of 4 colormaps simultaniously.
    It does this using hardware which uses a list of up to 64 rectangles
    which determine which hardware map the pixel values inside the
    rectangle should reference.
    
    The problem seems to be the colormap not being installed.  This is one
    of those, X11 - Window Manager - Application Policy issues.  Colormaps
    other than the default must be CREATED.  These maps must then be
    installed by a client.  IF PHIGS doesn't install the map (and by policy,
    applications aren't supposed to do the install) then it's up to the
    window manager.  The window manager will install it when the window
    gets input focus or whenever else it's policy dictates.
    
    It's one of those things where everybody is told that to be good
    doobies they shouldn't do it, and then nobody does.  It makes sense
    when there is only a single colormap.
    
    What I don't understand is why PHIGS would create a TrueColor map?
    Are you sure it's not a DirectColor map?  If PHIGS used TrueColor
    then it could simply use the default map on the 24-plane system.
    It can create it's own TrueColor map, and the logic (though I don't
    know for certain) will probably load up a second TrueColor map into
    the hardware - which would exhibit the problem you describe.
    

Thanks for the info Fred.

     >Yes, the firefox can display from any of 4 colormaps simultaniously.
	It is still not clear whether the server is taking advantage of 
	the "4 colormaps". 

    >What I don't understand is why PHIGS would create a TrueColor map?
	Truecolor is the default visual type on the Firefox, at least
	that is what the VMS doc says. Therefore, I don't believe that
	PHIGS is creating the Truecolor colormap.


    >It does this using hardware which uses a list of up to 64 rectangles
    >which determine which hardware map the pixel values inside the
    >rectangle should reference.
 
        What happens when the rectangles overlap, how does the HW decide what 
	to do?


This there any documentation/information on how the graphics hardware works, or
how the DECwindows implementation works with the graphics hardware. I have a 
copy of the HW specification but it does not talk much about the graphics 
options. I know that the graphics HW was originally designed for VWS but the 
corporation switched to DECwindows before VWS had a chance to implement anything.
Therefore, it is not clear what features of the graphics HW the DECwindows
server DDX components are taking advantage of.

Brad

>Thanks for the info Fred.
>
>     >Yes, the firefox can display from any of 4 colormaps simultaniously.
>	It is still not clear whether the server is taking advantage of 
>	the "4 colormaps". 

I don't remember 100% of the details, but essentially, the server breaks up the
windows into "layers", which are essentially rectangles which are in the format
that the hardware wants for determining which colormap to use.  As Fred says,
the h/w can deal with 64 of these rectangles.  It is possible for a complicated
layout of windows to end up requiring more layers than are available, even with
only a small number of colormaps in use.  This could be causing the problem, I
suppose.

>    >It does this using hardware which uses a list of up to 64 rectangles
>    >which determine which hardware map the pixel values inside the
>    >rectangle should reference.
> 
>        What happens when the rectangles overlap, how does the HW decide what 
>	to do?

They don't overlap.  That is why you can't just assign a layer to a window and
be done with it.  You have to break the whole thing up into rectangles that the
h/w can deal with.

>I know that the graphics HW was originally designed for VWS but the 
>corporation switched to DECwindows before VWS had a chance to implement anything.
>Therefore, it is not clear what features of the graphics HW the DECwindows
>server DDX components are taking advantage of.

Au contraire...Or at least partial contraire...the DW Server groups worked
closely with the Firefox h/w folks during the design phase.  The FF folks also
contributed to the multiple colormap stuff in the X protocol.

But as to your problem:  There is, as you probably know, a window attribute which
tell what colormap the window wants.  In most servers this is used only by the
window manager to insure that the right cm is installed.  Thus it is only
important that the top-level window have the right cm.  The FF on the other hand
actually uses this field internally to tell the h/w which cm to use when it is
scanning a particular window.  Thus, it is important that ALL windows which
expect to have a non-default colormap have the correct colormap set into their
attributes.  I think that normally attirbute inheritance should take care of
this (i.e. the default colormap is that of the parent).  However, you need to
figure this carefully.  Another point is that the toolkit does not deal with
non-default colormaps very well.  I don't know the details, but I know a lot
of folks have found it difficult to do just the right thing.  You should be
able to search for other notes in this conference about that subject, or maybe
Leo or Mike or someone will provide more info.

Burns

    Not knowing the details, but just having been asked to make some
    changes to the code that does all this magic:  Yes, the Firefox
    server uses the ability when the applications and window manager
    all work together.
    
    The 64 rectangles are actually a priority ordered stack (if I
    understand correctly) and the hardware actually manages the overlap.
    But this isn't (I think) your problem, your problem seems to be getting
    the colormap installed at the appropriate time.
    
    Burns is right on target regarding the Firefox design - it was a
    outgrowth of the Firefly hardware done on the west coast which ran
    Unix.  It was very much a DECwindows project, and there was never
    any serious attempt to make VWS run on it - and nobody from VWS
    had input to it's design.
    
    The problem is that X11 applications and the window manager must all
    work together to properly install the colormaps.  Now, there may be a
    bug someplace that is not causing the installations to take place -
    I suggest a QAR on the problem describing in detail how to reproduce
    the problem.
    

A common problem with applications has been associating
colormaps with the window that uses them.  It is
possible on some systems to create the colormap and
install it without associating the colormap with the
window.

On the 35x0, this means that you may not see the colors
in the window.

The application must use XSetWindowColormap or it's
equivelent to make sure that the system knows what
colormap goes with the window.

Mike

Thanks Fred/Burns/Mike,

I am attempting to reproduce this problem but so far I can't reproduce it. I am
also trying to verify with the customer if the non-phigs application is 
forcing a colormap load, etc. Right now it is not clear exactly what the 
application is doing with the colormap, outside of creating one. I will let you 
know what happens.

Oh, I also stand corrected on the Firefox/VWS design statements made in earlier
notes. I believe I was mis-informed.

Regards,

Brad