Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re: XView application without olcursor?
Message-ID: <9003090650.AA11211@Larry.McRCIM.McGill.EDU>
Date: 9 Mar 90 06:50:42 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 34

> This is a valid request for change--if the toolkit cannot find the
> OpenLook fonts, it loads in bitmap data and uses that instead.  The
> only problem we would have with this is increasing the library size.

I thought shared libraries eliminated the problems associated with
growing a library, at least by small amounts (like this).

> The advantage of using a font over bitmaps is that many XView
> applications can share the same OpenLook glyph images---by using the
> same font.  When using bitmaps, you either have to download the
> bitmap over the wire each time you draw (cheap on the server) or
> allocate server side bitmaps for each application (cheap on the wire
> and potentially disatrous for the server).

> Is there a way to allocate server pixmaps as sharable objects?  i.e.
> one client allocates a pixmap as "read-only" so other clients could
> use it.  That would make the problem much easier to solve.

Pixmaps are already shared objects - if you can find out the XID of a
pixmap, you can access it.  The only problem is that when the
allocating client disconnects, the pixmap goes away.  I see at least
two ways to solve this problem:

1) All OL clients are prepared to get BadPixmap errors and check to see
   if the bad pixmap ID is one of the OL glyph substitutes, and if so,
   recreate the pixmap.

2) The glyph substitutes are created via a separate server connection
   whose close-down mode is set to RetainPermanent.

					der Mouse

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