Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!uunet!snorkelwacker!bloom-beacon!SABER.COM!jimf
From: jimf@SABER.COM
Newsgroups: comp.windows.x
Subject: Re:  set viewport on X
Message-ID: <9008101412.AA02883@armory>
Date: 10 Aug 90 14:12:45 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 28

|Well, gee, you could always keep a handful of variables around and do
|the scaling yourself.  It's a little tedious - you need to provide a
|"virtual" version of each of the X drawing routines you use - but I see
|no reason why it wouldn't be perfectly workable.

If you build yourself a library that implements a retained graphics
environment (ie it remembers shapes and their orientations until you
destroy them) it's not too tedious, and the application will become
simpler to boot.

When porting a large application from SGI GL to X11 a couple of years
ago, we did exactly that.  This technique has other advantages -- you
only need to tune one area to make painting or repainting faster, or
to fix weirdnesses in the X rendering model.  With only a fair amount
of effort we managed to get almost-reasonable rendering of screens
with 100,000+ shapes (`shape' meant text, lines, ellipses, rectangles,
and polygons -- but mostly ellipses and polygons) on a color Sun
386i/250 under X11R2.  Repair times were very fast, and having the
objects in local structures meant that implementing `pick' was easy
and had good performance even on that dog of a machine.

An added bonus is that porting such a library to other graphical
environments is a snap.  We ported the above mentioned library from
X11R2 to SGI GL in well under a day and tuned it in less than a week.

jim frost
saber software
jimf@saber.com