home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / atari / st / tech / 6292 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  3.1 KB
  1. Path: sparky!uunet!mcsun!Germany.EU.net!rrz.uni-koeln.de!not-for-mail
  2. From: aeg03@rrz.uni-koeln.de (Jan T. Kim)
  3. Newsgroups: comp.sys.atari.st.tech
  4. Subject: Lazy AES (wase: Sending objc_draw to a memory buffer)
  5. Date: 16 Dec 1992 11:41:25 +0100
  6. Organization: Regional Computing Center, University of Cologne
  7. Lines: 48
  8. Message-ID: <1gn14lINN1095@rs1.rrz.Uni-Koeln.DE>
  9. References: <memo.812189@cix.compulink.co.uk>
  10. Reply-To: kim@vax.mpiz-koeln.mpg.dbp.de
  11. NNTP-Posting-Host: rs1.rrz.uni-koeln.de
  12.  
  13. In <memo.812189@cix.compulink.co.uk> apelled@cix.compulink.co.uk (Adam Pelled) writes:
  14.  
  15. >    Incidentally. Has anyone else noticed that when a window is moved back
  16. >into full view that the redaw is for all the work area. A bit lazy of the
  17. >AES methinks.
  18.  
  19. Yes, I noted that, and it bothers me quite a lot.  I'm  not  that
  20. brilliant  a  programmer  that I can redraw rectangles in a split
  21. second (which could have to do with the stuff I'm  drawing,   too
  22. --  should  I start bitching about having no clean way of drawing
  23. VDI output to a virtual screen from which  I  then  could  blit),
  24. therefore  it  sometimes  can really drive me crazy. The solution
  25. I've done for myself is making redraw routines  interruptible  by
  26. pressing <Esc>, which is, of course, a kludge...
  27. But what's even more foolish about the AES, if there's a  window,
  28. and  only a fraction of a slider is overlapped by another window,
  29. and now the first window is topped, the AES will send the  redraw
  30. event  for the full workspace of that window, although no part of
  31. it needs to be redrawn. I'd really appreciate if  this  could  be
  32. optimized.
  33.  
  34. >    Also the rectangle list is not exactly optimum. i realise it must be
  35. >recursive and that there must be some kind of inheritance, but it seems a
  36. >shame that it couldn't be merged by the OS and save the overhead for all the
  37. >apps having to redraw too many rectangles. With losts of windows this gets to
  38. >be quite drastic. Try an experiment and draw a box outline in a  multi window
  39. >environment you'll see what i mean.
  40.  
  41. Do you mean by this that the  AES  should  automatically  restore
  42. window  parts  that  become  uncovered again? It seems to me that
  43. there is  a  justification  for  having  the  programm  redrawing
  44. windows   rather   than  the  AES,  because  the  algorithms  and
  45. information for redrawing the windows must be buried somewhere in
  46. the  program anyway, while the best the AES could do is to create
  47. a bitmap somewhere containing the whole contents  of  the  window
  48. and  blitting  the  visible  parts  from there to the appropriate
  49. rectangles of the window. If VDI output redirection was possible,
  50. one  could  redirect  stuff  to  there  and  write  a library for
  51. displaying such a virtual screen in a window once,  which  would,
  52. from  then  on,  be  just  as  good as if the AES maintained that
  53. screen and took care of the redrawing.
  54.  
  55. Greetinx, Jan
  56.  
  57.  +- Jan Kim -- X.400:    S=kim;OU=vax;O=mpiz-koeln;P=mpg;A=dbp;C=de -+
  58.  |             Internet: kim@vax.mpiz-koeln.mpg.dbp.de               |
  59.  |                                                                   |
  60.  *----=<  hierarchical systems are for files, not for humans  >=-----*
  61.