Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!mitech!gjc
From: gjc@mitech.com
Newsgroups: comp.windows.x
Subject: Re: Fast redraw after expose events
Message-ID: <9905@mitech.com>
Date: 4 Apr 91 09:55:44 GMT
References: <1991Apr4.053315.25887@sserve.cc.adfa.oz.au>
Organization: Mitech Corporation, Concord MA
Lines: 74

In article <1991Apr4.053315.25887@sserve.cc.adfa.oz.au>, gfreeman@csadfa.cs.adfa.oz.au (Graham Freeman) writes:
> We are building a graphics application using X windows, and do not
> know what is the best way to handle window exposures in the server.
> 

You described how you can keep a lowlevel BITMAP oriented representation
of your drawing. Is that really the only level you have available
without a tremendous amount of recomputation? How many draw-lines,
and draw-string operations do you do, as compared with BIT oriented things?

                 X-LIB         X-Server

Application => Draw-Line   => ........
   ^        => Draw-String => ........
   |        ================> Bitlevel
   |                             |
   |                             |
   \----------------------------/ 

So currently your idea of Redisplay is entirely at the bit level.
And one idea for redisplay you have is to suck the bitlevel back from
the server into your application. And of course that doesn't work
always. You have two choices.


(1) Get rid of the use of XLIB for non-bitlevel operations.
    Have your own Draw-Line and Draw-String.
    I know of applications that do this, and it can be very effective.
    For example, a complex graphical ICON which has a representation
    in terms of lines, and is generally dynamically SCALED is more efficiently
    converted into a bitmap ONCE (for each scale level) and then draw
    using the bitmap representation. Obviously you need to know how to
    code a good DRAW-LINE, DRAW-CIRCLE, and handle fonts and such.
    This is well known technology. (You can snarf it from the MIT X-Server).
(2) Keep a DISPLAY-LIST data structure by inserting a level of code
    inside your application, between it and how you currently use the
    XLIB level.


             D-LIST      X-LIB         X-Server

Application |******| => Draw-Line   => ........
            |******| => Draw-String => ........
            |******| ================> Bitlevel

 

A smart display list will keep track of, at least, a RECTANGLE
that bounds each graphics object. This is helpful in optimizing
redisplay on expose events. The two tricky areas are:
(1) modeling the behavior of overlapping X-LIB operations.
(2) dealing with ERASE concepts. (In a sense, garbage collecting
    the display list in space and time). This is the most important
    special case of #1.

A typical display list environment might keep a 2-dimensional floating-point
coordinate system with scrolling and zooming.

Along these lines DIGITAL has something in field test called GObE,
part of the Digital Graphical Interface Tools which is in field test.

Efficiency and extra layers of complexity is a big issue in these things.
The old VAX window system, VWS/UIS had this display list capability, but
at least with techniques used and the horsepower available in the UVAX-II,
it was not really a win. 

Generally the idea of a turning a common set of line-circle-string
oriented operations into a cached bitmap at a certain scaling is missing
from these general purpose display-list environments. (Unless there is
some kind of "macro" capability. And in the case fo DGIT/GOBE, you can
choose to make something a Widget at a certain point).


-gjc