home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / fj / maillis / xwindow / 18785 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.3 KB
  1. Path: sparky!uunet!stanford.edu!sun-barr!sh.wide!wnoc-tyo-news!scslwide!wsgw!wsservra!onoe
  2. From: graeme@labtam.labtam.oz.au (Graeme Gill)
  3. Newsgroups: fj.mail-lists.x-window
  4. Subject: Re: new FAQ? (programming) masking Pixmaps *efficiently*
  5. Message-ID: <1992Dec21.111143.19629@sm.sony.co.jp>
  6. Date: 21 Dec 92 11:11:43 GMT
  7. Sender: onoe@sm.sony.co.jp (Atsushi Onoe)
  8. Distribution: fj
  9. Organization: Labtam Australia Pty. Ltd., Melbourne, Australia
  10. Lines: 35
  11. Approved: michael@sm.sony.co.jp
  12.  
  13. Date: 21 Dec 92 03:45:12 GMT
  14. Message-Id: <1992Dec21.034512.18081@labtam.labtam.oz.au>
  15. Newsgroups: comp.windows.x
  16. References: <1g45bpINNavm@agate.berkeley.edu>, <1992Dec18.012904.15093@thunder.mcrcim.mcgill.edu>
  17. Sender: xpert-request@expo.lcs.mit.edu
  18.  
  19. In article <1992Dec18.012904.15093@thunder.mcrcim.mcgill.edu>, mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
  20. > In article <1992Dec15.152852.2528@miki.pictel.com>, oj@miki.pictel.com (Oliver Jones) writes:
  21. > > In article <1992Dec11.180230.10091@elroy.jpl.nasa.gov> sns@bondi.jpl.nasa.gov (Sam Southard) writes:
  22. > 
  23. > >> The server in question is probably doing the common thing and
  24. > >> converting clip-masks to rectangle lists.
  25. > 
  26. > Yes...but the choice of this implementation means that clip-masks that
  27. > don't decompose nicely into rectangles will be expensive to set and
  28. > somewhat expensive to use.
  29. > 
  30. > This implementation of clipping made sense in R3, before SHAPE, when
  31. > most clipping regions were the union of a few rectangles, though even
  32. > then, using it for client-specified GC clip masks (which are reasonably
  33. > likely to be complex) strikes me as at least questionable, requiring
  34. > further examination and thought.
  35.  
  36.     The reason anything more sophisticated has been put in the "too hard"
  37. basket (I guess) is that you basically would have to go around and duplicate
  38. every piece of rendering code in the X server. You then have to add an
  39. arbitrary bit clipping mask to one half of the duplicated code on top of
  40. everything else you have to do to get pixels on the screen (reading the
  41. destination, doing the logical op, masking with the plane mask, clipping
  42. to the clip rectangle). There is no incentive for anyone to do this while
  43. very few applications make use of an arbitrary bit mask. Application writers
  44. will tend to avoid using arbitrary clipping masks because they know they will
  45. be slow.
  46.  
  47.     Graeme Gill
  48.