Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!ncar!ames!lll-winken!uunet!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: How does the i860 compare as a graphics (co)processor?
Message-ID: <6419@cbmvax.UUCP>
Date: 29 Mar 89 01:46:11 GMT
References: <21971@agate.BERKELEY.EDU> <977@quintus.UUCP> <1989Mar25.222551.9141@utzoo.uucp>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 20

In article <1989Mar25.222551.9141@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <977@quintus.UUCP> lawrence@quintus.UUCP (Lawrence Byrd) writes:
>>This question is motivated by the increasing complexity of window systems
>>and the obvious need for ways of speeding them up.  It is depressing that
>>one needs a system in the 5 to 10 MIP range before the newer window systems
>>(such as various toolkits on top of X) start responding crisply...
>
>The cynic would say that we need less-baroque window systems.  The one on
>AT&T's Blit responds crisply with a lousy little 68000 running it.

	Half of the problem is "baroque" (otherwise known as Berkeley disease)
windowing systems, the other half is the cost of context switching between
the windowing system and the processes using it.  The second problem can be
dealt with using threads (as demonstrated by the Amigas Intuition windowing
system).  The first problem is one of design - keep efficiency and user
response time/drawing artifacts in mind when designing - don't design by
committee, and don't build baroque systems on top of other baroque systems.

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup