home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / atari / st / tech / 5653 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  2.5 KB
  1. Path: sparky!uunet!munnari.oz.au!bunyip.cc.uq.oz.au!uqcspe!cs.uq.oz.au!warwick
  2. From: warwick@cs.uq.oz.au (Warwick Allison)
  3. Newsgroups: comp.sys.atari.st.tech
  4. Subject: Re: CPX v1.00 Bug?
  5. Message-ID: <11055@uqcspe.cs.uq.oz.au>
  6. Date: 16 Nov 92 01:25:20 GMT
  7. References: <BxLLvF.4C1@brunel.ac.uk>
  8. Sender: news@cs.uq.oz.au
  9. Reply-To: warwick@cs.uq.oz.au
  10. Lines: 76
  11.  
  12. cs90ijr@brunel.ac.uk (Ian J Ray) writes:
  13.  
  14. >Now, *sometimes* XControl misses a _single_ pixel line along the left edge
  15. >of the redraw area.
  16.  
  17. >i.e.
  18. >                +---------------+
  19. >       +--------|       |       |
  20. >       |===Contr|      / \      |
  21. >       |        |               |
  22. >       |        |   Atari....   |
  23. >       |        |               |
  24. >       +--------|               |
  25. >            |    [ OK ]     |
  26. >            +---------------+
  27.  
  28. >       +--------|----------+
  29. >       |===Contr|l Panel===|
  30. >       |        |          |
  31. >       |        |          |
  32. >       |        |          |
  33. >       +--------|----------+
  34.  
  35. >                    ^single pixel line left.
  36.  
  37. >This problem seems to depend on the 'alignment' of the XControl window
  38. >on the desktop. Has anyone else had this problem? What is the latest
  39. >version of XControl?
  40.  
  41. This happens with almost every acc in existence.  The problem is that the fill patterns
  42. are not aligned to the object being drawn.  For example, using the 50% fill pattern will
  43. give you either:
  44.  
  45.    ###################
  46.    # # # # # # # # # #
  47.    ## # # # # # # # ##
  48.    # # # # # # # # # #
  49.    ## # # # # # # # ##
  50.    # # # # # # # # # #
  51.    ## # # # # # # # ##
  52.    # # # # # # # # # #
  53.    ## # # # # # # # ##
  54.    ###################
  55.  
  56. or 
  57.  
  58.    ###################
  59.    ## # # # # # # # ##
  60.    # # # # # # # # # #
  61.    ## # # # # # # # ##
  62.    # # # # # # # # # #
  63.    ## # # # # # # # ##
  64.    # # # # # # # # # #
  65.    ## # # # # # # # ##
  66.    # # # # # # # # # #
  67.    ###################
  68.  
  69. depending on where you draw the screen.  The trouble then occurs when the GEM window move
  70. code ***raster copies*** your window, rather than redrawing it.  If it redrew the object,
  71. all work work (although MUCH slower).
  72.  
  73. The only solution I know is to align you windows according to what pattern appears in
  74. them (eg. allign on odd (or even) pixels for the 2x2 fills, and 4-pixel boundaries for
  75. the 4x4 fills... and so on).
  76.  
  77. ... or don't use the VDI fill routines.
  78.  
  79. IMO, it isn't a problem.  It just looks a bit ugly on those RARE occasions when it occurs.
  80.  
  81. --
  82. Warwick
  83. --
  84.   _-_|\      warwick@cs.uq.oz.au            /Disclaimer:
  85.  /     * <-- Computer Science Department,  /  
  86.  \_.-._/     University of Queensland,    /   C references are NULL && void*
  87.       v      Brisbane, Australia.        /  
  88.