home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / windows / intervie / 3216 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  1.5 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!sgigate!sgi!fido!marktwain.rad.sgi.com!linton
  2. From: linton@marktwain.rad.sgi.com (Mark Linton)
  3. Newsgroups: comp.windows.interviews
  4. Subject: Re: Minimizing damage to a canvas
  5. Date: 18 Nov 1992 19:49:59 GMT
  6. Organization: sgi
  7. Lines: 19
  8. Distribution: world
  9. Message-ID: <1ee6p7INN10b@fido.asd.sgi.com>
  10. References: <BxvJ3n.AI3@world.std.com>
  11. Reply-To: linton@marktwain.rad.sgi.com (Mark Linton)
  12. NNTP-Posting-Host: marktwain.rad.sgi.com
  13.  
  14. In article <BxvJ3n.AI3@world.std.com>, grier@world.std.com (The Political Crony) writes:
  15. |> I'm involved in a monitoring application where a number of meter-style
  16. |> display glyphs will be updated from a comm channel coming in through
  17. |> some Dispatch methods. All the updating per se seems to be fine. My
  18. |> question pertains to update of the various displays as required.
  19. |> 
  20. |> It is possible for more than one meter to be updated at a time.  The
  21. |> natural mechanism for forcing a display update would be to put a patch
  22. |> around the meter and call the redraw() method. However, if more than
  23. |> one such redraw() occurs on spots widely separated on the canvas, the
  24. |> damage area will be the rectangle that contains all the damages,
  25. |> causing unchanged areas to be redisplayed.
  26. |> 
  27. |> Is there some way to avoid the extra drawing without kludging in the
  28. |> checking?
  29.  
  30. You can call redraw on the patch and then call repair on the window
  31. to force an update.  This will cause an extra draw traversal, but less
  32. actual drawing.
  33.