home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / windows / x / 20352 < prev    next >
Encoding:
Text File  |  1992-12-18  |  2.6 KB  |  64 lines
  1. Newsgroups: comp.windows.x
  2. Path: sparky!uunet!newsflash.concordia.ca!sifon!thunder.mcrcim.mcgill.edu!mouse
  3. From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
  4. Subject: Re: new FAQ? (programming) masking Pixmaps *efficiently*
  5. Message-ID: <1992Dec18.012904.15093@thunder.mcrcim.mcgill.edu>
  6. Keywords: Pixmap, mask, bitmap, graphic context
  7. Organization: McGill Research Centre for Intelligent Machines
  8. References: <1g45bpINNavm@agate.berkeley.edu> <1992Dec15.152852.2528@miki.pictel.com>
  9. Date: Fri, 18 Dec 92 01:29:04 GMT
  10. Lines: 53
  11.  
  12. In article <1992Dec15.152852.2528@miki.pictel.com>, oj@miki.pictel.com (Oliver Jones) writes:
  13. > In article <1992Dec11.180230.10091@elroy.jpl.nasa.gov> sns@bondi.jpl.nasa.gov (Sam Southard) writes:
  14.  
  15. >> Since my application will have arbitrarily-sized images, I decided
  16. >> that I would use the clip_mask.
  17. > Good call!
  18.  
  19. In a conceptual sense, yes.  This is what clip-masks are for: clipping.
  20. Unfortunately,
  21.  
  22. > Der Mouse wrote:
  23. >> The server in question is probably doing the common thing and
  24. >> converting clip-masks to rectangle lists.
  25. > This is done, behind your back, in the server.
  26.  
  27. Yes...but the choice of this implementation means that clip-masks that
  28. don't decompose nicely into rectangles will be expensive to set and
  29. somewhat expensive to use.
  30.  
  31. This implementation of clipping made sense in R3, before SHAPE, when
  32. most clipping regions were the union of a few rectangles, though even
  33. then, using it for client-specified GC clip masks (which are reasonably
  34. likely to be complex) strikes me as at least questionable, requiring
  35. further examination and thought.
  36.  
  37. >> Must I retain all graphics commands and re-issue them when an area
  38. >> of the window is exposed?
  39. > In general, yes, you must.
  40.  
  41. Well, you can use a pixmap to cache the results of the drawing on the
  42. server.  This has its price, of course: slower drawing (because you
  43. have to draw to both the window and the pixmap) and memory use.
  44.  
  45. >> I had planned on retaining a pixmap with the window contents for
  46. >> this purpose.
  47. > OK, but all drawing will have to take place first to the window, then
  48. > to the pixmap.
  49.  
  50. Well, you could draw to the pixmap first - it makes no difference, as
  51. long as you don't copy from one to the other in between drawing
  52. something to one and drawing it to the other.
  53.  
  54. > X gives you no reliable way to copy stuff from the window to the
  55. > pixmap in such a way that the pixmap is a true copy of the window.
  56.  
  57. I wonder if it would be worthwhile to provide a way to tell the server
  58. "here's a pixmap, use it as if it were backing-store for this
  59. window"...might be worth thinking about.
  60.  
  61.                     der Mouse
  62.  
  63.                 mouse@larry.mcrcim.mcgill.edu
  64.