Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!husc6!bu-cs!madd
From: madd@bu-cs.BU.EDU (Jim Frost)
Newsgroups: comp.windows.x
Subject: Re: Fast, infinitely undoable graphics.
Message-ID: <32290@bu-cs.BU.EDU>
Date: 4 Jun 89 19:37:54 GMT
References: <2483@rice-chex.ai.mit.edu> <4243@ficc.uu.net> <2532@wheat-chex.ai.mit.edu> <4260@ficc.uu.net>
Reply-To: madd@bu-it.bu.edu (Jim Frost)
Followup-To: comp.windows.x
Organization: Software Tool & Die
Lines: 40

At the company I worked for just a few short months ago, we had the
task of porting a very object-oriented graphical application to X
Windows.  Since the application was object-oriented, and the objects
could be manipulated (scaled, moved, drawn, undrawn, etc), we had
basically the problem you have.  Since we were porting to a Sun X
server, we had a tremendous incentive to make the resulting code be
pretty efficient, and I think we did fairly well at that.

What we did was keep a tree of objects.  We had three kinds of
objects: shapes, which were obvious primitives such as point, line,
circle, rectangle, and text; objects, which were composed of shapes
and which could be opaque or transparent, active ("touchable") or
inactive, and some other properties; and surfaces, which were
basically windows (but which had properties such as transparency,
floatability, and "touchability" which are difficult to impossible to
do under X) which could have either objects or shapes drawn on them.

To get reasonable draw speeds, we did two things.  First, we always
drew on a pixmap rather than directly on the display window, with
drawn areas copied in a single block to the window.  X refresh
requests could therefore be satisfied with merely a copy, which was a
huge gain considering the complexity of the displays we were dealing
with (50,000 shapes were not uncommon).  Second, no drawing was done
until an explicit or implicit refresh was done (implicit meant that an
input routine was called, obviously requiring the display to be
updated).  A list of areas where the display needed to be updated was
kept, and only those areas which were affected were ever redrawn.  To
keep things simple, anything that was in an affected area was redrawn
whenever that area needed to be redrawn, and *only* those things were
redrawn.  There are many cases where you can loose a lot of
performance that way (eg when adding things but not removing them),
but we had limitations which caused me to leave it as it was.

This technique was very successful, and turned out to be very portable
as well.  We moved the application from the X environment to the SGI
GL environment in two days (it screamed on the SGIs).

jim frost
software tool & die
madd@bu-it.bu.edu