[GRASS5] [cworth@east.isi.edu: GRASS on iPAQ]

[Carl Worth]

On Oct 3, Glynn Clements wrote:
 [ Description of work-in-progress Xr/Xc libraries ]

 > 1. I would only consider it ready to use when either Xr is ubiquitous
 > or Xc is available. Making GRASS unusable on systems which don't
 > support the Render extension is out of the question, IMHO.

Yes, Xc is an important part of the transition strategy. That's why
the decision has already been made to not incorporate Xr into the
XFree86 tree until Xc supports client-side emulation of the Render
extension.

 > 2. We also need to allow for Windows. Either Xc needs to work there,
 > or we would need to find equivalent native functionality.

This is not an issue I'm addressing.

 > 3. We also need to allow for non-screen output, i.e. the PNG and CELL
 > drivers.

The plan is that Xc will have output options to things besides X
drawables. The current proposed list is PNG, PDF, and PS. These have
not been implemented yet.

PDF output would be trivial to implement right now. PNG will be
trivial once Xc has all of the client-side rendering code. PS support
will need some clever code to efficiently handle alpha-blended
rendering, (shoving out giant bitmapped postscript would not be hard,
but it's really not what I want to do).

 > 4. For the future, I would like to also allow hardcopy output in a
 > compatible manner.

I've got the same goal for Xr.

 > That would impose some significant constraints, primarily:
 > 
 > a) the architecture has to scale to much higher spatial resolutions
 > than are typical for screen display.

Xr should deal with this fine since it uses doubles for all
coordinates, hence it will be able to expose all the spatial
resolution of hardcopy output devices. Also, for screen display,
Render support 16 bits of sub-pixel precision for all coordinates.

 > b) OTOH, printers typically have low colour resolution (i.e. 1 bit per
 > component), and rely upon dithering.
 > 
 > c) A printer's framebuffer is often write-only, which precludes
 > read-modify-write operations such as alpha-blending, and XOR
 > plotting.

Yes, both issues need to be addressed. In some cases, (such as PDF
output), we can rely on the PDF implementation to take care of all of
this. Eventually, though, I expect all of this functionality to be in
Xr/Xc.

Anyway, that's just enough to say that, yes, I think we're dealing
with all of the issues that need to be addressed for an application
domain as sophisticated as GRASS. This was really meant just as a
heads-up that we are working on this rendering architecture that might
save a lot of work for future GRASS implementations.

Xr doesn't do everything that's needed today, but it does already
support anti-aliased, alpha-blended drawing of lines/cubic bezier
splines on an X drawable if anyone wants to take it for a spin. The
drawing API is also stabilizing quickly, and I would be very
interested in any feedback there.

I'll let you know when Xr/Xc are initially released. At that point
there should be enough functionality for GRASS to seriously consider
building a new rendering architecture on top of Xr.

-Carl

-- 
Carl Worth                                        
USC Information Sciences Institute                 cworth at east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203		  703-812-3725