Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!mstar!mstar.morningstar.com!bob From: bob@MorningStar.Com (Bob Sutterfield) Newsgroups: comp.windows.news Subject: Re: obsolete arguments against NeWS Message-ID: Date: 5 Jan 90 23:20:02 GMT References: <9001022135.AA05473@brillig.UMD.EDU> <20973@pasteur.Berkeley.EDU> Sender: news@MorningStar.COM (USENET Administrator) Reply-To: bob@MorningStar.Com (Bob Sutterfield) Followup-To: comp.windows.news Organization: Morning Star Technologies Lines: 26 In-reply-to: davidh@dent.Berkeley.EDU's message of 3 Jan 90 00:01:35 GMT In article <20973@pasteur.Berkeley.EDU> davidh@dent.Berkeley.EDU (David S. Harrison) writes: The merged server has promise [for applications that need raw drawing speed] simply because it allows you to use X for graphics intensive work. I don't want an interpreter in the way when I dump fifty thousand stippled rectangles into a window. It's my understanding that you'll still have an interpreter in the way when using the merged server. There are two interpretive language frontends on the same internal data structures driving the same display backend. One interprets PostScript and manipulates the internals appropriately, the other interprets the X11 protocol as a simple language (single threaded, no loops or branches, etc.) and also manipulates the internals appropriately. So if your task requires a lot of work of the PostScript interpreter, then indeed it may get in the way. But if the task is characterized more by fondling internals or squirting bits on a screen, the bottleneck moves further back in the pipeline. In that case, requests of both the X interpreter and the NeWS interpreter would experience the same performance. I suspect that your example (50K stippled rectangles) would be interpreted once by NeWS and then handed to the guys in the back room. (But then again, how would I know? We're still waiting for our xnews shipment.) Other tasks are probably better suited to illustrate your point.