[comp.windows.x] Is this an X11R3 RT server bug, or an Andrew cmenu bug?

wdc@ATHENA.MIT.EDU (Bill Cattey) (04/19/89)

I just took the newly cleaned up X11R3 Xibm server and ran Andrew on it. I was
told that the Save Under and Backing store code was buggy, so I disabled it.

When I posted my first menu under Andrew, the server hung up.

The menu code, when it notices the server doesn't do save unders, does its own
by grabbing the server and copying the bits under the menu.  Although grabbing
the server is considered anti-social, it is the thing to do if menus are doing
their own save-unders.

The problem is that the application never gets to the code that ungrabs the
server  it hangs up here:

        do {
            XIfEvent(display, &event, DiscardableEvents, (char *) &state);
        } while (exposeEvent->type != Expose || exposeEvent->window !=
state.parentWindow || exposeEvent->count != 0);

On the Vax, the first thing XIfEvent returns is an expose event with a count of
0.  The code runs to completion and all is well.

On the RT, XIfEvent returns repeatedly with a bunch of stuff with a variety of
count values, until it finally blocks.  My guess is that the author of this code
expected the server to do the application the courtesy of sending an expose
event with a count of 0 to signify it was the last Expose event in the queue.

By replacing the above code fragment with:

        while (XCheckIfEvent
        (display, &event, DiscardableEvents, (char *) &state))
               ;

The andrew application seems to run fine on the RT.  (I have not tested it on
the Vax.)

Who is right here?
Is the Xibm right, not giving an Event with count 0?
Was the author right to expect this?
Am I right in using this code?

-wdc

rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (04/19/89)

    Is the Xibm right, not giving an Event with count 0?

No, an event with a count of zero must occur at the end of an exposure chain.

    Was the author right to expect this?

Yes.