[comp.windows.x] Porting a real application to XView.

rburridge@SUN.COM (Rich Burridge) (11/21/89)

I've just about finished porting the Micromine mapping package to XView; I
thought you might like to know the kinds of problems I came up against, and
what I did to get around them.

Micromine is approximately 105,000 lines of C. The machine independent
graphics are isolated out into one file  which is about 950 lines for
SunView and 1100 lines for XView including comments.

The program has two modes.

The first is what I call "PC text" mode, which consists of treating the 
window as a 25 row by 80 column terminal. The only type of Sun graphics
required here are coloring areas and drawing text strings.

The other is a real graphics mode, and the graphics boil down to lines,
arcs, circles, text, filled and outlined polygons and flood fills.
The package originally came from the PC world, and used the HALO graphics
package there. I've cobbled up an emulation of the routines it uses in
SunView/XView.

The performance of the SunView version is quite acceptable running on a
3/60 with 8Mytes. My initial attempt was to do almost a straight conversion
from SunView to XView. On my 4/110C with 16Mytes, when the XView version was
running in "PC text" mode, the performance was acceptable. When it was it
graphics mode, it was unbelievably slow.

Here are a couple of the reasons why:

1) The flood fill routine is based on the one in the touchup program. It's
   literally was doing a pw_get on each pixel of the window, trying to
   determine if it should be filling it in on not. Whereas this is acceptable
   under SunView, this generates thousands of calls to the X server with
   XView. I've rewritten this so that I get a copy of the complete window 
   across first, then handle the modifications locally. I can still improve
   on this, but something that was taking three minutes to fill, is now
   filled in about one to two seconds.

2) The circle routine under SunView was done using the Bresenham algorithm,
   therefore generating a pw_polypoint. X11 has a XDrawArc routine. Again it
   was a case of cutting down on the amount of traffic between the client
   and the server.

In fact I did virtually all of the graphics in "graphics mode" with Xlib
intrinsics. I needed the equivalent of pw_set_region_rect under XView. I
tried using win_set_clip but I couldn't get it to work (not for the want
of trying!). So I used the X11 Xlib call XSetClipRectangles instead.

Syncing with the server was another fun issue. Because of the nature and
history of the program, I couldn't use xv_main_loop but had to rely on
notify[start,stop,dispatch] instead. I tried using the xv_set call
with the attributes SERVER_SYNC or SERVER_SYNC_AND_PROCESS_EVENTS, but I
ran into random core dumps. I ended up using XSync(dpy, 0) instead.

In fact it was getting so frustrating at times, that I took the XView
toolkit source and compiled up the libraries with debugging on, and link
the mm program with these, just to see what was going on. Did you know the
xview library is 14MBytes when compiled with the -g option?

One of the portability issues which I still face, when I try to get this
working under MIT X1R3 with the XView toolkit, is all the pixrect calls.
These are going to have to be replaced with equivalent Xlib calls. The
program currently uses the Sun rasterfile format to load and save screen
images. This is going to have to be changed.

Another portability issue is font formats. I have a special mm character
font. I've currently converted this to .fb format and made the appropriate
associated files. I've then added the extra font directory onto the font
path by having a little .psh script which gets called when the program
starts up, and uses the NeWS BuildFontPath operator.

This is fine for Sun and X11/NeWS, but this font should really be in
.bdf/.snf format and use xset to add the font path. I'll fix this up next
week.

With these early days of XView maturity, I'm not sure whether I'm fighting
XView bugs or mm bugs. This will improve with future toolkit versions.

The next application to port will be easier. I now have most of the basis
XView graphics building blocks, and can glue them together as needed.

I hope somebody finds this useful, and I'm indebted to the XView people
out there who have provided assistance with my problems.

    Rich.