Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!unido!tub!net
From: net@tub.UUCP
Newsgroups: comp.windows.x
Subject: X questions - (nf)
Message-ID: <60200001@tub.UUCP>
Date: Tue, 16-Jun-87 16:01:00 EDT
Article-I.D.: tub.60200001
Posted: Tue Jun 16 16:01:00 1987
Date-Received: Fri, 26-Jun-87 03:30:12 EDT
Lines: 75
Nf-ID: #N:tub:60200001:000:3905
Nf-From: tub!net    Jun 16 21:01:00 1987

I have a couple of questions about the X Window System.  I'm new to X
and to this newsgroup/list, so maybe the answers are obvious or the
questions have already been asked before.  I'm using X version 10 on an
Integrated Solutions Optimum V WorkStation.

1) Is there a way to define a temporary clipping rectangle for a window?
   If not, why?

   When a client receives an expose-region event, the XExposeEvent
   structure gives the coordinates of the region of the window that
   must be repainted by the client.  However, clients typically are
   kept simple so they can repaint only entire windows, not arbitrary
   rectangles within a window.  This causes unnecessary activity on the
   screen when, for instance, only a small part of a large window has
   been exposed.

   To avoid unnecessary repainting, the client must clip all drawing
   primitives with respect to the rectangle that has become visible.  This can
   be complicated, and I don't see a reason why the clipping should
   not be performed by the server.  It would be useful to have
   "XSetTemporaryClipping" and "XRemoveTemporaryClipping" requests that
   can be used to define (and remove) a rectangle within a window
   to which all further drawing requests are clipped.  One would
   set a temporary clipping on receipt of an expose-region event,
   then invoke the function to repaint the entire window, and finally
   remove the clipping.

   I can't find something like this in the Xlib manual.  Is there a way
   to obtain this functionality using existing X requests?

2) Is there a way to purge the Xlib request queue?  If not, why?

   There is a function to flush the output request queue, XFlush(),
   but I can't find a way to discard the contents of the request queue.

   Imagine the following typical scenario:
   A client submits several drawing requests, for instance, to draw a
   curve in a window.  The requests are buffered in the Xlib until the
   next call to XFlush(), XPending(), XNextEvent(), etc.  The drawing
   requests are based on certain assumptions about the size of the
   window, e.g. the curve is scaled so that if fits nicely into the
   window.  Now, the window gets resized.  Before this event is noticed
   by the client, the output queue is flushed (typically by a call to 
   XPending()).  The problem is that the requests that had been waiting
   in the queue are now executed in the wrong context, because the
   window has changed its size in the meantime.  The coordinates that
   have been supplied together with these requests may no longer be
   valid with the new window size (e.g. the curve should be rescaled);
   this can produce ugly glitches on the screen.

   Obviously, in addition to XFlush() one needs something like "XDiscard()"
   or "XPurge()" that can be used to throw away the current contents
   of the output request queue.  However, there remains the problem that
   some requests may have already been sent out by the Xlib, but have
   not yet been received by the server (for instance, they may sit somewhere
   in the connection to the server).

3) When a rubber box is displayed on the screen by XCreate(), the size of
   the box is the minimum window size (determined by the "minwidth" and
   "minheight" arguments to XCreate()).  This is counter-intuitive.
   Instead, a rubber box of the default size should be shown.
   It still could be reduced to the minimum size when the middle button
   is used for sizing the window.
   Is showing the minimum size a feature?  If so, how can I tell
   XCreate() to rubber band (and finally create) a box of the default size?


If you want to comment publicly, please send me a copy of your response
by E-Mail, too, because the news feed to developing countries like
Germany is very unreliable.

--
Regards,
    Oliver Laumann, Technical University of Berlin, Germany.
    ...!pyramid!tub!net   or   net@TUB.BITNET