According to Antti P Miettinen:
>
>I do not know details of X11 or GDI or the mechanism used in NT to
>bounce system calls back to user land etc so I can speak with the
>total confidence derived from complete ignorance.

I am somewhat better - I have the certificate that says I can play at
being NT admin at work (they made me do it, honest ;-) but I keep the
stuff at arms length - we have other people that have to deal with NT
so I can play unix :-)

> I think that
>graphics calls in NT work very differently from X11.

Yeah as you said, in NT the calls are calls directly into the OS
whereas with X11 the calls send messages to a server.  This means that
you can, as I am at the moment, remotely display an X11 session
without any horrible, ugly hacks.  NT 5 is supposed to have stuff in
it to do the same but all they are doing is bolting in the winframe
gunk by default rather than as an "after market" option.

>The observable fact is that NT 4 is a lot faster that NT 3.51 in for
>example filling out a list box in a dialog with 1000 entries.

What M$ did in the 3.51 -> 4 transition was wimp out on the HAL
(harware abstraction layer) and shift some of the driver code into the
NT kernel somewhat blurring kernel/driver layering.  I believe that
the idea was to have an abstraction layer between the kernel and the
driver to provide a clean interface for writing a driver - this got
tossed when it was found that performance sucked.

>process/thread in effect lowers its priority when executing graphics
>calls. Or the other way aroud - your low priority screen saver may
>starve a higher priority process/thread with time consuming graphics
>calls.
>

Mmmmm I thought it was that the task actually on the display got a
boost by the scheduler, making the interactive performance quicker at
the expense of background tasks.

>
>Actually I think the soft priority levels used by different device
>drivers should be even configurable by user. I know just about nothing
>about the spl/ipl things in NetBSD so this might be very irrelevant
>now, but maybe in future NetBSD which supports hard real time
>applications :)
>

Now for some slightly tech-kern relevance... turning interrupts on/off
is not really the major problem with real-time.  If that was the only
thing then you could just have a syscall that turned the things off &
on at will.  The major problem is convincing the scheduler to run a
real time process within the time frame that the real time process
needs, i.e. right now.  The scheduler currently tries to share out the
cpu even handedly between all competing processes, rewarding ones that
give up their time slice early and penalising the ones that hog the
cpu.  A real time process needs to have the cpu when the need arises
not when the scheduler next looks for a process to run, even if you
put the RT process at the top of the run queue the RT process may
still need to wait up to a clock tick before it will get onto the CPU.
There was a hack done in linux that effectively ran a real time
process in an interrupt context but there are lots of constraints on
doing this.  I think that RT goes directly against the design aims of
the unix system and that it may be next to impossible to accomplish
without totally changing the design philosophy (just MHO ;-)

-- 
Brett Lymn, Computer Systems Administrator, British Aerospace Australia
===============================================================================
  +++ Divide By Cucumber Error.  Please Reinstall Universe And Reboot +++
  - Hogfather, Terry Pratchett.