home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / os / os2 / misc / 35431 < prev    next >
Encoding:
Internet Message Format  |  1992-11-05  |  3.1 KB
  1. Path: sparky!uunet!olivea!charnel!rat!usc!sdd.hp.com!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnews!shurr
  2. From: shurr@cbnews.cb.att.com (larry.a.shurr)
  3. Newsgroups: comp.os.os2.misc
  4. Subject: Re: Service Pack Results...
  5. Message-ID: <1992Nov5.155029.20839@cbnews.cb.att.com>
  6. Date: 5 Nov 92 15:50:29 GMT
  7. References: <1992Nov3.144905.2229@cbnews.cb.att.com> <1992Nov5.102042.16261@monu6.cc.monash.edu.au>
  8. Organization: AT&T Bell Laboratories, Columbus, OH
  9. Lines: 46
  10.  
  11. In article <1992Nov5.102042.16261@monu6.cc.monash.edu.au> parry@yoyo.cc.monash.edu.au (Tom J Parry) writes:
  12. }larry.a.shurr (shurr@cbnews.cb.att.com) -- i.e., me -- wrote:
  13. }> This is my impression, as well.  PM Windows appear faster, but windowed
  14. }> VIO & VDM sessions are slower than before.  The VIO & VDM windows appeared
  15. }> to be updated in interleaved "zones" -- watch carefully during a full 
  16. }> screen paint or a scroll, though maybe it's less visible if you have a
  17.  
  18. I was not entirely correct when I said this.  Full screen paints appear to
  19. use this interleaved method, but scrolls don't.  Instead, it looks like a
  20. scroll is performed by redrawing the window from the bottom up.  Not a
  21. bitblt to be seen!  I find this unsightly as well as horribly slow.  I've
  22. stopped running TE/2 in a window because it's just too slow.
  23.  
  24. }I have been playing with Linux and X386 on a 486-33 recently and the speed
  25. }of X (running in 4MB with about 2MB free!) is awesome compared to the wps
  26. }especially in xterm windows. One of the reasons for this seems to be the
  27. }way xterm does screen updates. It seems to update the screen to what is
  28. }happening at the time of the update. So a long multi-page directory listing
  29. }may be done in 2 or 3 updates. Compared to OS/2's 50 updates for the same
  30. }action, it makes xterm much faster. 
  31.  
  32. I thought that was something that X Windows did routinely.  Maybe it's
  33. implementation-dependent and the implementations I've seen all do it.
  34. I certainly agree that the technique avoids "wasted motion," so to
  35. speak.
  36.  
  37. }When using full screen OS/2 sessions, I can get 128lines scrolled by in
  38. }0.78 seconds. I certainly can't see everything that is displayed. If I want
  39. }to I will pipe the output somewhere. In a windowed session, it scrolls each
  40. }line. If it just displayed the whole screen as it should appear at the
  41. }_time_ each update starts then the screen would scroll maybe 25 lines at a
  42. }time and things wouldn't be so slow and we'd be able to see as much as we
  43. }can from a full screen session. It's rediculous to redraw the screen for
  44. }every line of output if it's coming that fast.
  45.  
  46. Well... I don't want to argue the point since I agree fundamentally that
  47. when data are coming into the window fast enough, then line-by-line update
  48. is "wasted motion."  However, when the data aren't coming in very fast, at
  49. 2400 baud say, then line-by-line may be the way to go.  Notwithstanding our
  50. possible disagreement on this point, OS/2 windowed VIO & VDM sessions are
  51. so slow that it's impractical, even at low data rates.
  52.  
  53. Larry
  54. -- 
  55. Larry A. Shurr (las@cbnmva.att.com or att!cbnmva!las) speaking only for myself.
  56. EOR (end-of-ramble)
  57.