Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!ZIA.AOC.NRAO.EDU!cflatter
From: cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters)
Newsgroups: comp.windows.x
Subject: Re:  Why do so many "great" people dislike X?
Message-ID: <9009072150.AA17072@zia.aoc.nrao.edu>
Date: 7 Sep 90 21:50:59 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 42


Scott Gordon writes:

>	As someone who is going to be moving to an 'X' environment
>	for reasons of image processing, I am *really* worried about
>	the imaging functions in X.  I have heard very bad things about
>	these functions.  Well, actually, I just heard that they were
>	really bad, but was not really told the reasons.  Can anyone
>	expound on their experiences?  

When people talk about X lacking an "imaging model" they seem to be
referring to the fact that the Xlib primitives are pixel based and not
based on some display independent coordinate system.  I would rate this
as building mountains over molehills: if you want to draw in centimeters
or inches you can add another layer on top of Xlib (the necessary
information -- the pixel spacing in real coordinates -- is easily 
available).  Of course, for an image processing application pixel access
is probably exactly what you need.

Xlib has a rich set of primitives for drawing and image display.  Its main
disadvantages for image processing are that you have to pan and zoom in
software if this is required.

>	Also, there is a question (keeping in mind we know very little
>	about X right now) about whether software written in X will
>	work for any X peripheral.  If we have 2 different display
>	boards for example, do we have to have 2 different versions
>	of the software, or do the boards deal with the imaging calls and
>	(hopefully) are transparent to the user? 

You only need a different version of the X server for each board.  X
applications talk to the server using the X protocol and the server
translates their requests into the imaging calls suitable (and hopefully
optimised) for the board in question.  However, if you have a wide variety
of displays you might have to have alternate code branches for different
display types since devices with 24-bit "true colour" displays may need to
be treated differently from 8-bit pseudocolour displays if you are
displaying images (there are other distinctions between display types but
this is the most painful).  Take a look at Adrian Nye's "Xlib Programming
Manual" (Vol. 1 in O'Reilly's X Window System series).

			Chris Flatters