[169] in DCNS Development
[Bob Scheifler : status report, of sorts]
daemon@ATHENA.MIT.EDU (Peter Roden)
Thu Feb 13 07:58:03 1992
Date: Thu, 13 Feb 92 07:57:06
From: roden@MIT.EDU (Peter Roden)
To: developers@MIT.EDU
Cc: acmg@MIT.EDU
------- Forwarded Message
To: advisory@expo.lcs.mit.edu
Subject: status report, of sorts
Date: Wed, 12 Feb 92 19:50:46 EST
From: Bob Scheifler <rws@expo.lcs.mit.edu>
i wrote this a couple weeks ago, for the next issue of the X Resource.
(as such, it is not for republication elsewhere.)
In the past, I have usually refrained from saying very much in
public about what the X Consortium was working on, until the work
was close to completion. I would occasionally drop tidbits
in messages on xpert/comp.windows.x, but not much beyond that.
Now that I have stopped participating on xpert, this column seems
to present an insurmountable opportunity to keep people at least
a little bit informed. So, here are some tidbits, to give you
a flavor of the range of activities the X Consortium is now
engaged in, and an inkling of what the future might hold.
X Protocol
A two-month second public review of the ANSI draft standard
``X Window System Data Stream Definition'', otherwise known as the
X Protocol, was scheduled to begin in February, along with the first
public review of the mapping of the protocol onto OSI services.
The first public review resulted in some good clarifications in
the wording, an explicit set of pixelization constraints, and the
inclusion of new keysyms for Korean and for PC-style keyboards.
The first public review also demonstrated that a very small but very
verbose minority can force many people to waste considerable time
in order to satisfy the ANSI standards process. It will be interesting
to see what the second public review brings.
The X protocol currently restricts an individual protocol request
to a maximum of 262140 bytes. While this might seem sufficient
for most purposes, the PEX extension is starting to demonstrate that this
limit may be too low. So, we are considering a protocol extension
that would increase this limit to a 32-bit length for all protocol
requests. The extension is quite simple to define, but the impact
on server implementations is still being evaluated.
Low-bandwidth X
An effort is underway to define a standard for running X over
low-bandwidth connections. The goal could be described as
making X usable over 9600 baud lines, while supporting the
ability to run clients on both sides of the wire (viz.,
inside an X terminal as well as on remote hosts).
Transport independence is also a goal. Jim Fulton and Dave
Cornelius at Network Computing Devices are leading the design effort,
and have put forth NCD's existing XRemote protocol as a starting point,
but significant design changes are under discussion. XRemote uses a
host-side pseudo X server that accepts standard X protocol connections
and translates to a compressed protocol with the real server;
all X state remains resident in the real server. To avoid round-trip
delays through a slow link, some state might profitably be cached in
the host-side pseudo server. For example, caching window properties
would
improve the performance of a remote window manager, and would speed up
application startup (e.g., reading the resource manager property).
Multi-threaded X server
John Smith is leading a small group at Data General, with help from
Keith Packard at the X Consortium and engineers from Omron,
in the design and implementation of a multi-threaded X server.
The main goal of this work is to produce a server that maintains
user-level interactivity in the face of protocol requests (e.g.,
rendering of complex 3D graphics) that take a long time to execute.
Another goal is to take advantage of multi-processor hardware for
server execution. The work is being based on a subset of POSIX Threads
(compatible with Mach C Threads). An overview of the server is presented
in a paper by John Smith the previous issue of the X Resource.
Multi-threaded Xlib
Stephen Gildea at the X Consortium has started reworking the
Xlib implementation to support multi-threading. Many
of the hooks have long been in place, but some tricky details
had never been worked out (e.g., permitting output in one
thread to continue when another thread is waiting for input), and
post-R4 code was not thoroughly reviewed with respect to
concurrency issues. The work is also being based on a subset of
POSIX Threads. No changes to the specification are currently
contemplated.
X Test Suite
UniSoft Ltd. has been working under contract to the X Consortium since
the summer of 1990 on a comprehensive Xlib and X protocol test suite.
The assertions for the suite were generated from the R4 standards.
The suite is designed to run under the Test Environment Toolkit
jointly developed by the Open Software Foundation, Unix International,
and X/Open. A pre-release of the suite has already proven very valuable
in finding problems in the Xlib and X server sample implementations,
and the suite is now being used routinely for regression testing
of Xlib and server code changes at the X Consortium.
PEX Protocol
Based on experience with the PEX 5.0 protocol, an upward compatible
minor revision of the protocol has been designed to deal with some of
the most pressing problems. The PEX 5.1 protocol adds these features:
Escapes; the ability for the server to restrict what drawables PEX can
be used on; renderer-based picking and echo support, and hierarchical
Z-buffer control during traversals. In addition, a number of conventions
have been established (e.g., governing allocation and interpretation of
vendor-private values) for using existing mechanisms to promote
interoperability.
Beyond PEX 5.1, work is in progress on a major revision of the PEX
protocol. Throughout the PEX design process we have attempted to
track the stable parts of PHIGS PLUS, but it has always been a moving
target. With ISO standardization of PHIGS PLUS nearing completion,
it is time to reconcile the PEX protocol and add in missing features.
At the same time, a number of other problems with the current PEX
protocol will be fixed; changes that could not easily be made in
an upward compatible fashion. Examples are changing length fields
to support larger OutputCommands and reworking structure store so
that structure identifiers (which are assigned arbitrarily by the
application in PHIGS) do not have to be remapped into the
server-specified X resource identifier space. Finally, various
advanced rendering facilities beyond PHIGS PLUS are being
considered, such as surface anti-aliasing, per-vertex or per-facet
transparency, texture mapping, multi-pass traversal, and dynamic
modeling-coordinate light sources.
PEXlib
When the PEX protocol was originally being designed, the political
climate made the idea of a low-level interface to PEX unacceptable.
PHIGS was the only interface to PEX; to bless any other interface
would appear as adverse competition with ANSI. Times
have changed, however, and in the past year the demand for a
common PEXlib has grown considerably. The goal is to define a
lowest-level Xlib-like interface to PEX providing complete
access to the protocol (e.g., complete access to immediate mode
graphics, which is not provided by PHIGS) on which toolkits and
higher-level
interfaces (such as PHIGS) can be built. Naturally, it is expected
that some application developers will also choose to code directly to
PEXlib,
but the design emphasis is on high performance more than ease of use.
An existing PEXlib design done at Digital Equipment was selected as a
starting point for the work; this PEXlib is available on the R5
contributed
software tape. Various design changes are being discussed, particularly
in
the areas of buffering OutputCommands, incremental OutputCommand
generation,
memory allocation, and multi-thread support.
Multi-buffering Extension
Public review of the draft standard Multi-buffering/Stereo extension
closed in the fall of 1990. Since then we have been waiting for
``proof of concept'' in the form of hardware-based implementations,
and have addressed minor issues as they arose from implementation
experience.
PEX has always been viewed as major consumer for this extension, and in
a sense we have been waiting for PEX implementations to progress far
enough
to force implementation of the Multi-buffering extension. That is
finally happening, and PEX vendors want a stable base to ensure
interoperability, so we should soon be ready to finish off
standardization of the Multi-buffering extension. Recent
discussion has focused on the desire to alias a window resource id
to a back buffer for drawing requests, so that ``buffering unaware''
code can be used in double-buffered operation without rewriting code.
Interaction with the Synchronization extension is also being discussed.
We are still waiting for a real implementation of stereo windows,
and may have to drop this facility in the interests of finalizing
the standard.
X Image Extension
The major features of XIE are compressed image transport (e.g.,
G3/G4 fax, JPEG), image enhancement operations (e.g., filtering,
contrast adjustment), geometric transforms (e.g., scale, rotate,
translate, mirror, crop), and rendition operations (e.g.,
dithering, color resampling, color mapping). Processing is
done on revisable form images inside the X server, with
asynchronous execution of imaging pipelines.
The X Image Extension has progressed slowly in the X Consortium.
Joe Mauro at Digital first brought a specification of XIE to the
X Consortium in the fall of 1988. At that time a preliminary
review was conducted, but not enough members could commit resources
to a full technical review. Joe and his group continued to work
on the extension, interacting informally with interested parties.
A new version of the specification was brought to the Consortium
in the fall of 1990. After another preliminary review, and a
delay to permit a few members to gather sufficient resources,
full technical review has been in progress since March 1991.
Some major design changes have been made in the course of
the review, particularly in the area of pipeline construction
and execution, but it appears that we are now nearing closure.
A concern for vendors of low-end X terminals has been the server
code size needed for a complete XIE implementation, compared to
what might be sufficient to handle bitonal view-only applications
(e.g., fax display). The feasibility of a bitonal view-only subset
of XIE was still under discussion at the time this article was written.
Synchronization extension
Tim Glauert at Olivetti Research has proposed his Synchronization
extension as a standard, and technical review is now in progress.
This extension provides mechanisms that clients can use within the
X server to synchronize request execution with other cooperating
clients (e.g., in mixing independent graphics streams) or to
synchronize with real time (e.g., executing during vertical retrace
or at specific intervals). The draft version of the specification
that Consortium review started with can be found on the R5 contributed
software tape, and a sample implementation can be found in the anonymous
ftp contrib directory on export.lcs.mit.edu. Of course, this draft
is subject to change during the Consortium review.
Better Typography
It is expected that an effort will get underway to provide better
typographic support to X applications. Possible features include:
pair kerning and track kerning; dynamic scaling, rotation, and
obliquing of font objects; subpixel-precision metrics; metrics to
support vertical writing; direct access to outline font information;
support for multiple-master fonts; dynamic remapping of glyphs to
glyph indices, and grayscale fonts. Downloadable fonts are also
a subject of discussion. Work in this area requires not only an
X protocol extension, but a companion extension to the font server
protocol as well. Jim Flowers has been leading a group at Digital
working in this area, was very active in development of the
ISO 9541 font standard, and is expected to be a leader in the Consortium
effort.
2D Graphics
A group has been discussing improved 2D graphics support in X.
The discussion originated from work by Paul Jensen at Digital on
a 2D graphics extension called ``Wormhole'', and from a desire to
achieve high-performance client-side PostScript (or other page
description language) rendering.
Features being discussed include downloadable fonts, server-side support
for PostScript-style paths, a PostScript-oriented trapezoid primitive,
a PolyPolygon request, PolyPoint and PolyLine requests that permit colors
to be changed per element, a StencilFill primitive, and splines.
Others have expressed interest in adding general affine coordinate
transforms.
It is still too early to know how these interests will play out.
Internationalization
R5 shipped with two sample implementations of Xlib internationalization
support and several different Input Method servers in contributed
software.
Unfortunately, not all of the Input Method servers use the same network
protocol to communicate with Xlib. A given Xlib implementation, and
hence
a given application, only supports one network protocol, which means that
end users do not have the freedom to switch between all of the different
Input Methods. The X Consortium is now beginning to work on a standard
Input Method protocol, to promote this level of interoperability.
We are also looking at defining interfaces to permit new Input Methods
(whether entirely local to Xlib or server-based) and new Output Methods
to be installed into Xlib dynamically, either by explicit request
of the application or transparently through dynamic linking inside Xlib.
The goal is to provide a portable way to add support for a new locale
(e.g.,
one not supported directly by the Xlib vendor).
In addition, there is a desire to deal with two writing system aspects
not dealt with in R5: bi-directional text (e.g., Hebrew and English
or Arabic and English) and vertical writing (e.g., Chinese).
Bi-directional text is problematic, given lack of support from the
underlying locale mechanism. Vertical writing would be made possible
given the typographic extension.
C++ Toolkit
Mark Linton at Silicon Graphics continues to lead an effort to
design a next-generation toolkit for X in C++. InterViews 3.0,
available on the R5 contributed software tape, represents one
snapshot in the evolution of the toolkit but there are still
many issues to deal with, such as multi-threading, better event
handling, device-independent color, internationalization, and
multi-media. This effort has suffered in the past from not having
enough X Consortium members taking an active role in designing
or evaluating the toolkit. We hope that situation will change soon.
Inter-Client Communication Conventions
Work has begun on a new revision of the ICCCM standard. Among
the topics being discussed are: a general framework for registering
and contacting service providers (e.g., window manager, clipboard,
session manager, root window background manager); sharing colors
across colormaps to minimize technicolor flashing; session management;
improved selection handling, and drag-and-drop. The drag-and-drop
work is not aimed at mandating a particular user interface, but at
providing common underlying mechanisms to achieve interoperability
in the face of multiple user interface styles. A good paper by
Ellis Cohen of OSF and Gabe Beged-Dov of Hewlett-Packard in the
previous issue of the X Resource describes many of the issues surrounding
drag-and-drop.
When Can I Have It?
The X Test Suite, PEX 5.1, and PEXlib should be available later this
year,
if work continues on schedule. The rest are nominally targeted as part
of Release 6. When is R6? Well, that depends on how the schedules of
the various activities work out. Sound a bit circular? You bet.
------- End of Forwarded Message
