Around 10 o'clock on Apr 23, Alan Coopersmith wrote:
> 1) Draw a line in the sand (say at what's done in XFree86 4.2.0 or 4.3.0) > and declare that to be RENDER 1.0. Either finish the spec, or leave the > transformations and other bits that still aren't defined out until version > 1.1 -- just set a stable, complete spec instead of the current unfinished > spec. Agree that future versions will be backwards compatible. The current protocol revision advertised by the server is 0.2, reflecting the reality that the implementation lags the documentation by quite a bit. What isn't document is the precise definition of this version, I think it would be a reasonable idea to do that. Note that there are some significant things implemented in the code that haven't made it back to the documentation. I haven't made any incompatible changes in the protocol since the first implementation, and I can't see any reason why I would have to in the future, the parts that have been implemented have been rather extensively tested and widely deployed -- changing them would be very hard. While it wasn't really my plan to take a long time in this work, I've been rather sidetracked with the font part and haven't managed to work my way back into the server for the remaining rendering pieces. It's worked better than I thought it would; pieces are added as applications are ready to start using them, making the implementation and testing integrated which yields significantly better code and fewer regressions. One thing which I have remained consistent in doing is to modify the protocol version advertised by the server each time more of the protocol has been implemented. A precise pixelization specification for the polygons has been somewhat difficult to arrive at, just a few weeks ago I discovered a flaw in my current design that can be rectified by moving from 24.8 coordinates to 16.16; it's nice to discover such things before getting to deployment; this does point out that the current protocol specification should have a clear demarcation between what is know to be correct and complete and areas which haven't yet been nailed down. I don't see any significant issues in codifying the current RENDER subset as version "0.3" or whatever and continuing to flesh things out as we need them towards an eventual 1.0 release. > 2) Document the API. I can't find any formal documentation of the API, > just the headers/source & the extension protocol documentation. Someone > could probably combine those two into the start of an API spec. The API is designed to be a trivial wrapper around the protocol, so the semantics of the operations need only refer to the related protocol requests. It would be useful to build a document that layed out the argument order and precise datatypes used in the interface. This hasn't been one of my top priorities; given a thin interface, the existence of the protocol spec and the header files, the API hasn't so far confused anyone that I know of. > I can't speak for all the commercial vendors, but at least Sun is very > concerned with stable interfaces, as our OS release cycles are now about 2 > years long, and while the existing bits of the Render API seem stable, the > documentation says that much work remains to be done and it's unclear if > that includes changes to the existing protocol/API. I think the protcol document should delineate the sections which are "stable" from those which are still in development, that should be relatively easily done by marking portions with the protocol revision they first appear in. Note that XFree86 has it's own deployment issues; it's no easier for us to drive users and developers to migrate than any other X implementation, so the concerns you have about standardization and change are something at the fore of every discussion about future directions within XFree86. It would be great if you could help us clarify the current state of the Render specification and the server implementation, protocol and API. Keith Packard XFree86 Core Team Compaq Cambridge Research Lab _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
