🚀 go-pugleaf

In article <1990Dec5.165513.16570@eagle.lerc.nasa.gov> fsset@bach.UUCP (Scott E. Townsend) writes:
>In article <1411@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes:
>>Hmm, I can't see much benefit from this besides ease of programming.
>>IMHO, it is sufficient to map a smaller rectangular part. The drawing
>>routines can be adapted without much peformance loss.

>is a good size performance gain.  For example, a quick circle drawing
>routine would slow down a fair amount if it had to worry about drawing
>across this rectangular window into the real image.
Not quite that. The circle drawing algorithm has more to do than poking
pixels into the frame buffer, so checking is only a small fraction. But
what is even more important is that you can determine from the start
coordinates when you cross window boundaries which reduces overhead even
more.

>Essentially, one could say the reason I would like a flat memory space is
>that I don't like the headaches a window has.  Headaches cause harder
>programming, larger code, and usually measurably slower code.
As I said, it is _easier_ to write code for a memory mapped framebuffer
but doesn't imply major performance loss. Think of a framebuffer addressed
through the concatenated row and column number which isn't a flat contigous
memory at all but which is surely faster to access for graphics purposes.

>I like the 680x0's simple address space better than the 80x86's segmented
>address space too ;-)
Well, the 8086 has the fault that you NEED segments to address all memory.
I wouldn't argue against segmented memory if the segments can be as large
as the logical address space. Think of UNIX where you have a segmented
address space (usually one segment per process) even with 680x0 processors.

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."