Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!bionet!arisia!roo!xerox!kent
From: kent@Xerox.com (Chris Kent)
Newsgroups: comp.windows.x
Subject: Re: OW as a PostScript X server...
Message-ID: <628@roo.UUCP>
Date: 19 Nov 90 21:21:59 GMT
References: <9011131842.AA08663@islanders.> <1990Nov13.231333.23226@crl.dec.com> <2787@exodus.Eng.Sun.COM> <1990Nov15.021857.21755@crl.dec.com>
Sender: news@parc.xerox.com
Reply-To: kent@Xerox.com (Chris Kent)
Organization: Xerox PARC
Lines: 39

Well well. Ignore news for a few weeks and see what happens!

I'm surprised no one else has answered definitively yet, to tell the
truth. The answer is that you're both right. To really, truly
synchronized the DPS extension and X primitives, you need to use
DPSWaitContext (or the clientsync operator, depending on which way
you're trying to force the synchronization). But unless you're counting
on the results of some PostScript operation, you probably never need to
synchronize explicitly, because the painting operators execute very quickly.

An example of a place you must synchronize is if you're using DPS
operations to image into a pixmap, and then want to look at the contents
of the pixmap (say, with GetImage or CopyArea). In that case, doing a
WaitContext is necessary to make sure that the contents of the pixmap
are complete before copying the bits away. This is unfortunate, perhaps,
but programmers usually get around this by creating the pixmaps once,
ahead of time, and then just doing the CopyAreas when the bits are
needed during program execution.

So yes, Jim, the extension follows your rule of least astonishment: if
you do a DrawLine followed by a show, the text gets rendered second.
But, if you do DrawLine/show/DrawLine, the second line may get painted
before the text has finished painting, depending on a whole bunch of
things (mainly whether or not the characters are in the cache, if the
font has been run before, and so on).
In some cases, this will matter. In most, it won't.

But there's another advantage of having a single connection and having
DPS a real part of X, rather than in a separate environment with a
separate connection: sharing of resources and resource IDs. Some of the
DPS operators know about X resource IDs, so you can do things like
change the gc and drawable with a DPS operator. In particular, the gc
and drawable are part of the graphics state that is saved by gstate or
the user graphics state operators. This makes using a single context to
display output on several drawables very easy.

Hope that clears things up a bit. 

chris