Conference bulova::decw_jan-89_to_nov-90

With the multi-client, multi-server, multi... model, there is a fairly high
probability that you could get collisions on that sort of information exchange.
The typical one is I ask for the number of colors, the server answers, while
I am deciding what to do with them you reserve some.  When my color request
comes along, there are fewer than I thought.  That is why an algorithm that
attempts to allocate and then tries alternative approaches based on success
or failure is superior to asking and the reserving.

Dick

    I'll answer the direct question: The philosophy of X is "allocate, then
    succeed or fail".  This is true of all the server-allocated resources.
    There is no convenience routine to tell you how many more windows can
    be allocated, or what the largest pixmap that can be created is.
    
    I'll reinforce the point made in the earlier reply:  Take the
    asynchronous multiple-access nature of X very seriously  Whatever
    number the server (hypothetically) tells you is the free number is
    potentially not valid at the time your client reads it as other clients
    may have allocated the pixel values by the time you get around to
    allocating them.
    
    Most of the "silly" convenience routines of Xlib return time-invariant
    values.  Having the server return values for shared resources that vary
    over time leads to a very large class of potential client application
    errors.  Note the common Xlib error of writing to a
    created-but-not-yet-mapped window.  Timing is everything.
    
    To tackle the premise of .0: No, I don't think that a Xlib application
    needs to find out how many read/writeable pixels exist in the server
    (you must mean the available entries in a pseudocolor colormap).  I
    think it would be really distracting or confusing to have the
    appearance of an application change based on whether 10 or 12 colors
    were available.

    Thanks for your responses.  I must admit the multi-server/multi-client
    allocation problem had not occured to me before.  This makes it clear
    why the server would want to allocate all time-variant quantities when
    asked.
    
    I must say, however, that even if I accept the fact that my
    XFindFreePixels routine should be XAllocFreePixels, it still should
    exist, encapsulating the famous XAllocColors in a loop trying to find
    all the available pixels in the colormap of the server to which one is
    attached.  This would be as least as convenient as say XtSetSensitive
    is in the toolkit; replacing mabye two lines of code with one.
    
    Also, I may be working in a somewhat closed environment, but my
    applications always try to get as many pixels are available and then
    create an HLS color scheme with those that are read/write.  It
    definately changes the way my application looks and works if there is
    24 not 124 pixels available.  This I have seen on workstations running
    PHIGS.  My applications are strictly imaging and thus NEED a spectrum
    of colors to be effective, I think.  In these situations, using named
    colors for instance is not acceptable.
    
    This, however, is a rat-hole, I would say.  Noone is going to put a
    routine like this in the next release of DECWindows because of this
    note and I got a reasonable answer already.
    
    Thanks,
    	John

John,

I think Pat has a point about consistency.  While it is useful for your
application to make do with what it can get (ie: it will never get 128 colors
on a 4 plane VS2000) it also makes sense to try for as much consistency as
possible.

One approach to that would be to use some scheme to attempt to allocate as many
colors as possible from the default color map.  If that is below some minimum
value (or percentage of the colors available) then attempt to use a private
colormap.

Approaches like that prevent the application from degrading to far on a heavily
used system.

Dick