Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!bloom-beacon!mcgill-vision!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.sys.next
Subject: Re: Just what we need - PC programs for the NeXT
Message-ID: <1990Dec5.131935.18703@thunder.mcrcim.mcgill.edu>
Date: 5 Dec 90 13:19:35 GMT
References: <1990Nov28.234910.28347@murdoch.acc.Virginia.EDU> <25678@uflorida.cis.ufl.EDU>
Distribution: na
Organization: McGill Research Centre for Intelligent Machines
Lines: 56

[stuff about direct access to framebuffer memory]

To address the original question, I'd use DKIOCGADDR.

> Writing trash like this may be acceptable for PC's running Windows or
> Mac's running finder.  However, garbage like this is not acceptable
> for modern UNIX workstations, *especially* ones shipped with the
> premier window-system-development tool on the market.

Speak for yourself.  I consider it barely usable.

> I have noticed that the Lotus people broke the Sun version of 123 the
> same way, by explicitly going out of their way to write directly into
> screen memory.  As a consequence, when this program hangs as it does
> occassionally, your window manager (SunView) is shot dead in the
> water.  Will people never learn?

I suspect it is actually something else.  I have often seen things draw
on the raw framebuffer while SunView is running, and not once have I
even heard a report of this hanging SunView - until now.

>> Sigh, the price of portability is control.
> Incorrect.  With some trivial Postscript, you may write to any pixel
> in any window you open.

How does one arrange for this to happen automatically when some area of
memory is poked?  I'm not about to try to rewrite every framebuffer
access in ddx/cfb to generate PostScript instead.

And what's more, I shudder to think how much performance penalty would
be involved in changing a three-instruction sequence to modify the
framebuffer into code to generate the relevant PostScript and send it
to the window server.  I would be amazed by less than three orders of
magnitude slowdown - which is, of course, completely unacceptable.  The
thing is already slow enough to verge on unusable.  (In my opinion.
Others more tolerant than I think it eminently usable.)

>> Flames about portability and philosophy to /dev/vid0.
> I did this, but it wrote trash all over my screen, and then crashed
> my window manager and hung my machine.

Odd.  When my code clashes with the window server writing to the
framebuffer, I just get corrupted screens.  It's never crashed
anything.  (Said code has problems, but they're due to my playing fast
and loose with DPS, not due to my drawing on the framebuffer behind the
window server's back.)

Yes, such techniques are dangerous; they require care.  They decrease
portability (which is not always a problem).  But there are times when
they are *the* way to address some need.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu