On Monday, 16 November 1998,
     JEFF DUNLOP wrote to IVAN TODOROSKI about PM drawing priorities...


 IT>>   Nope... checked it THOROUGHLY before I sent the message. If you start
 IT>>   ping with the normal (default) priority, and drag windows around, it
 IT>>   virtually stops! The five lines DON'T show up immediately when you
 IT>>   stop dragging the window (remember, full-window dragging must be on).

 JD> I turned full window dragging on here (did not realize that it
 JD> makes a difference) and observed Ping and Dir/s both to continue
 JD> running nearly at full speed. I can make them a bit jerky if I
 JD> drag very quickly all over the screen. Perhaps your video driver
 JD> is poorly designed? I have a Matrox Millenium II running at
 JD> 800x600x64k.

  Well I have a relatively slow machine (486/100), with a reasonably
  fast card, but with HORRIBLY slow and unoptimzied drivers for it.

  BUT before you say "I knew it" or "I told you so" :)
make sure you've
  read my previous messages from this packet.

  I am forced to use a slow driver because the fast drivers I have for
  my card work only under Warp3 :(

  You are not noticing this effect because you have a fast machine with
  a fast card with fast drivers for it, so the windows redraw faster
  than you can drag them, and CPU cycles are released. I didn't notice
  this effect also under Warp3, since I used fast optimized drivers
  then. But I'm noticing it now.

  It seems that there is a priority boost associated with the redrawing
  of the windows, and if the driver is slow enough, CPU cycles will not
  be released between redraws while you're draging the window.

  So you now have a higher priority thread which is not releasing any
  CPU cycles! And if you've read Denis' explanation, you now what this
  means. It means that any lower priority threads will NOT get any CPU
  cycles (except by means of the starvation boost) till the dragging
  stops.

  The priority of this redrawing falls somewhere between Server, delta
  31 (0x31f) and Time Critical, delta 0 (0x800). I know this because
  0x31f threads stop, and 0x800 threads don't.

  This estimate can be further refined by taking into account the fact
  that the starvation boosts preempts the redrawing of windows (that's
  why processes in the background run in short bursts one second apart
  even though the redrawing doesn't release any cycles - that's when the
  starvation boost hits them).

  So, by consulting the priority table Denis Tonn posted, we can see
  that the starvation boost results in increasing the thread priority to
  0x61f for Regular priority threads, which gives the upper limit for
  the priority of PM drawing.

                 0x31f < PM drawing < 0x61f

  It may be possible to further refine this estimate by changing the
  priority values in the priority table. One could try lowering the
  starvation boost until it no longer preempted the redrawing of
  windows. That would be the exact priority of PM redrawing. But it
  seems that only I could do it, since most of you cannot observe the
  effect because of your fast machines. I may try this when I have some
  more free time on my hands...

                                                            - Ivan -

.!. Sir! Romulan warbird decloaki»®õ÷üÁ NO CARRIER
--- Terminate 5.00/Pro [OS/2]
 þ TerMail/QWK þ