[comp.windows.x] Handling ExposeWindow events for nested windows

mlp@dana.UUCP (04/08/87)

I am implementing a program which makes use of nested windows.  When the
outermost window is resized (by the user) the application is responsible
for resizing the subwindows of the main window.  Unfortunately each subwindow
receives an ExposeWindow event before its parents and when I resize the windows
they get a further series of ExposeWindow events. 

I am trying to implement my program in an enhanced version of the Xr toolkit
(from HP).  In this version each window can have a callback function which is
called whenever a new event arrives for that window.  This localizes the
handling of events for each window and makes it easier to process events and
to add new windows.

The problem is that if I simply handle ExposeWindow events by redrawing the
window I redraw each subwindow twice for each main window resize.  Once before
the main window is notified of the resize and once after the sub window has beenredrawn.  I also appear to be getting some ExposeWindow events when a window
covering my subwindows is iconified.

Does anyone know of a generic way of handling ExposeWindow events that will
reduce the number of redraws to the minimum necessary to keep the screen
upto date?  Assuming that I have also enabled ExposeRegion events under what 
circumstances will I get ExposeWindow events.

Mark Patrick
hplabs!dana!mlp

RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (04/09/87)

I haven't got the time for long explanations, but
"fixed in Version 11" applies reasonably well here;
you can get better control over how subwindows
should be affected when their parent is resized.

tsf@theory.cs.cmu.edu.UUCP (04/09/87)

In article <141@dana.UUCP> mlp@dana.UUCP (Mark Patrick) writes:
>I am implementing a program which makes use of nested windows.  When the
>outermost window is resized (by the user) the application is responsible
>for resizing the subwindows of the main window.  Unfortunately each subwindow
>receives an ExposeWindow event before its parents and when I resize the windows
>they get a further series of ExposeWindow events. 

You might want to look at the source for the bitmap program; it uses a
sneaky kind of recursion to do the job.

I seem to remember reading somewhere that this would be fixed in
version 11.

Tim Freeman

Arpanet: tsf@theory.cs.cmu.edu
Uucp:    ...!seismo!theory.cs.cmu.edu!tsf

wyatt@cfa.UUCP (04/10/87)

> [...] ExposeWindow is sure useful,
> but from a programmer's point of view a ResizeWindow event would have
> been EXTREMELY helpful too. 

It seems to me that if you do an XQueryWindow() after an ExposeWindow
event, and compare the window size to the previous size, you effectively
have the ResizeWindow event.
-- 

Bill    UUCP:  {seismo|ihnp4}!harvard!cfa!wyatt
Wyatt   ARPA:  wyatt@cfa.harvard.edu
         (or)  wyatt%cfa@harvard.harvard.edu
      BITNET:  wyatt@cfa2
        SPAN:  17410::wyatt   (this will change in June)

jensen@winery.DEC.COM.UUCP (04/10/87)

If you are going to do this under X10, the best approach I have seen
is to defer processing Exposure events until you receive an event
which is not an expose event (or you run out of events).  Then you
look at the last exposure event and test to see if it is a resize.
If so, discard all the previous exposure events; otherwise process
them.  Whether this will work for you depends on the nature of
the application; you will have to be careful not to discard an
exposure event you really need to process.

For an example of this, take a look at bitmap.c in the X.V10R4 release,
in particular ProcessEvent, ProcessEventReally, and HandleExposure.
ProcessEvent makes a call to HandleExposure, which in turn recursively
calls itself until the event string terminates.  Then if the last
exposure event is not a resize, HandleExposure returns with a
"PROCESS_IT" status, which will cause the stack to unwind, processing
the deferred events (N.B.: in reverse order).  Otherwise, HandleExposure
returns a "DISCARD_IT" status, causing the deferred events to be
thrown away.  There are some details I have skipped, but these routines
are a good starting point.

Regards,


					/Paul Jensen
					 Western Area Operations
					 Digital Equipment Corp.
					 Santa Clara, CA

haynes@DECWRL.DEC.COM.UUCP (04/10/87)

	> [...] ExposeWindow is sure useful,
	> but from a programmer's point of view a ResizeWindow event would have
	> been EXTREMELY helpful too. 

	It seems to me that if you do an XQueryWindow() after an ExposeWindow
	event, and compare the window size to the previous size, you effectively
	have the ResizeWindow event.


I guess this point hasn't been made strongly enough.

	SERVER ROUND TRIPS ARE VERY EXPENSIVE

Avoid them at all cost. Cache things in the client, keep local data
structures in your program, stand on your head, whatever. A server
round trip is almost always more expensive.

Doing a QueryWindow to simulate a ResizeEvent IS A LOSE. Keep your size
locally, and make sure you serialize your XEvents properly, and you can
KNOW your size all times. Then checking exposes for resizes is cheap
and easy. This is the technique we used in the X10 toolkit to simulate
resize. In X11 of course, resize is provided.

The X protocol is great, but you need to understand the reality of its
implementation to use it well.

	-- Charles