home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / windows / x / 15656 < prev    next >
Encoding:
Text File  |  1992-08-26  |  3.1 KB  |  70 lines
  1. Newsgroups: comp.windows.x
  2. Path: sparky!uunet!news.gtech.com!noc.near.net!gateway!miki!oj
  3. From: oj@miki.pictel.com (Oliver Jones)
  4. Subject: Re: Problems in X event handling
  5. Message-ID: <1992Aug26.115308.2412@miki.pictel.com>
  6. Organization: PictureTel Corporation
  7. References: <1992Aug19.063720.2994@ctr.columbia.edu>
  8. Date: Wed, 26 Aug 1992 11:53:08 GMT
  9. Lines: 59
  10.  
  11. In article <1992Aug19.063720.2994@ctr.columbia.edu> raum@isoa3.ba.ttu.edu (Raum Pattikonda) writes:
  12. >During a display, a typical client program recognizes the "expose" event, 
  13. >computes the data and sends for display to the X server.
  14.  
  15. Actually, Expose events come in series.  A well-written client
  16. recognizes and handles a whole series of Expose events.  The "count"
  17. member of the Expose event's struct helps clients understand where
  18. each individual Expose event appears in its series.
  19.  
  20. >For many 
  21. >applications such as VLSI circuit layout, editing, construction 
  22. >and display may take easily 2 to 3 minutes over a busy network. 
  23.  
  24. The long elapsed time probably has very little to do with network
  25. congestion, unless it's the application which is using NFS or
  26. some other network service to read large files.
  27.  
  28. >Typically 
  29. >the user resizes the window as soon as it appears. In such a case 
  30. >the expose event is acknowledged two times and the image is displayed 
  31. >two times... This problem can be 
  32. >solved if the clients were written properly to handle asynchrounous
  33. >events or if Xlib has a watch dog to look for events asynchrounously 
  34. >and take appropriate action.
  35.  
  36. What you actually want to do is notice when the user has resized the
  37. window and abandon the ongoing redraw operation.  Xlib provides very
  38. raw support for this, whereas Xt provides good support.
  39.  
  40. What to do is this:
  41. (1) organize your program so the long-running (2-minute) redraw 
  42.     operation is carried out in a series of short (approx 50 millisecond)
  43.     calls to an Xt work proc.  (Work procs are called by the Xt main
  44.     loop whenever there are no events or other inputs to handle).
  45. (2) write your Expose event handler so it uses XtAppAddWorkProc to
  46.     register your work proc when it detects a series of Expose events.
  47.     If the previous work proc is still active, your Expose handler
  48.     should use XtRemoveWorkProc to remove it (this is the way you
  49.     abandon the redrawing for obsolete Expose events).
  50. (3) set the drawing window's bit_gravity to ForgetGravity.  That
  51.     way X will clear the entire window and send an Expose series
  52.     when the user resizes it.
  53.  
  54. The tricky part of this suggestion is part 1, because it means you
  55. must reorganize your redraw operation from a single loop to a series
  56. of calls to a subroutine.
  57.  
  58. Many refinements to this basic method are possible, to improve the
  59. application's performance when Expose event series result from
  60. operations other than the user resizing the window.  
  61.  
  62. >In our example the the watch dog will 
  63. >peek and detect the second expose event before the action is taken for 
  64. >first expose event and will make client discard the first expose event. 
  65.  
  66. This probably doesn't help much unless you repeatedly look ahead for
  67. subsequent Expose events as your drawing progresses.
  68.  
  69. Oliver Jones
  70.