* Replying to a message in : SAVEAREA

On Saturday, 21 November 1998,
     MARIO SEMO wrote to IVAN TODOROSKI about PM drawing priorities...

 MS> * Copied from: OS2PROG
 MS> Hallo IVAN!

 MS> Antwort auf eine Message von IVAN TODOROSKI an ALL:

 IT>>   I noticed recently (and I wonder how I never noticed it before) that
 IT>> when you drag a bigger sized window accross the desktop (with full
 IT>> window dragging enabled) most applications in the background simply
 IT>> stop. Try typing DIR /S in an OS/2 command window and drag the window
 IT>> around... you'll notice how the listing stops while you're dragging
 IT>> it. Same happens if you drag other windows.

 MS> again it has to do with the way VIO output is handled. when you run a GIF
 MS> viewer which has its own PS it can draw even when dragged. when you are a
 MS> stupid cmd session (like cmd.exe) it locks the output.

  It also locks the output of ALL other programs! And not only the
  output, but the activity too!

  Seek & Scan files was running when I was trying this, and disk
  activity STOPPED when I draged VIO or folder windows around. I also
  had a program running in a minimized full-screen session constantly
  beeping (and doing NO screen output whatsoever) in the background, and
  the beeping simply STOPPED when I started dragging some window (ANY
  window) around. I was simply flabbergasted.

  This problem is now totally gone since I patched the kernel priority
  table, so the problem WAS INDEED in OS/2.

 MS> (eq: i have a text search utility with about 5 threads. one thread
 MS> searches the hard disk for files, one thread read in file, one
 MS> thread searches the files and one thread is for VIO output. and
 MS> when you drag my app, one the vio thread stops (automatically) but
 MS> all other threads continue running in the background).

   Maybe you have fast drivers and/or fast card and/or fast machine, so
   you're not observing this effect since the window gets redrawn faster
   then you can drag it. Most of the people with Pentiums and Matrox
   Millenium cards didn't notice this effect simplu because their
   hardware was too fast and the video driver actually had CPU cycles to
   spare.

 IT>>   As a final note, I tried this on a Win98 system at my friend's home,
 IT>> and when you type DIR /S and move the window (or move other windows)
 IT>> with full window draging, the listing of directories doesn't stop,
 IT>> and   behaves just as you would expect (slows down a little). It
 IT>> looks   rather nice when you move the window with directories
 IT>> scrolling by in   it.

 MS> but its definbitly as stupid as possible (the behaviour). its just
 MS> stupid CPU cycle eating. who looks at a DIR / S output while
 MS> dragging a window?? my machine has more important things to do.

  Well... I don't think it is stupid, since it also stops all the other
  more important things on my machine! Infact, it totally freezes all
  non-TimeCritical threads!

  I don't look at the output of dir /s program either, I was only
  pointing it out as a test of performance.




 MS> Servus, Mario!

 MS> -!- FleetStreet 1.21 PR#2
 MS>  - Origin: LC/32 Development Team, http://www.kirchnersoft.com
 MS> (2:310/14.11)
 MS>                                                                           
 MS>       
 MS>                                          


                                                            - Ivan -

.!. CURSOR: What you become when your system crashes.
--- Terminate 5.00/Pro [OS/2]
 þ TerMail/QWK þ