[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

X Strike Force Render SVN commit: r83 - in trunk/renderproto-0.9.2/debian: . patches



Author: dnusinow
Date: 2005-12-26 22:42:01 -0500 (Mon, 26 Dec 2005)
New Revision: 83

Added:
   trunk/renderproto-0.9.2/debian/patches/001_protocol_and_library.diff
   trunk/renderproto-0.9.2/debian/patches/series
Modified:
   trunk/renderproto-0.9.2/debian/changelog
   trunk/renderproto-0.9.2/debian/render-dev.install
   trunk/renderproto-0.9.2/debian/rules
Log:
* Have the render-dev.install file look for the library and protocol in the
  root dir instead of the installation target, since they're not installed
  by default any more
* Re-order patch target requirement so that it actually applies before
  configure
* Actually add the 001 patch and the patches/series file


Modified: trunk/renderproto-0.9.2/debian/changelog
===================================================================
--- trunk/renderproto-0.9.2/debian/changelog	2005-12-27 03:34:33 UTC (rev 82)
+++ trunk/renderproto-0.9.2/debian/changelog	2005-12-27 03:42:01 UTC (rev 83)
@@ -11,8 +11,11 @@
     These are elsewhere in the 7.0 source (where I pulled the tree from) so we
     need to artificially add them for now.
   * Make debian/rules use xsfclean and patch targets from xsfbs
+  * Have the render-dev.install file look for the library and protocol in the
+    root dir instead of the installation target, since they're not installed
+    by default any more
 
- -- David Nusinow <dnusinow@debian.org>  Mon, 26 Dec 2005 22:33:19 -0500
+ -- David Nusinow <dnusinow@debian.org>  Mon, 26 Dec 2005 22:40:11 -0500
 
 renderext (1:0.9+CVS20050905-1) experimental; urgency=low
 

Added: trunk/renderproto-0.9.2/debian/patches/001_protocol_and_library.diff
===================================================================
--- trunk/renderproto-0.9.2/debian/patches/001_protocol_and_library.diff	2005-12-27 03:34:33 UTC (rev 82)
+++ trunk/renderproto-0.9.2/debian/patches/001_protocol_and_library.diff	2005-12-27 03:42:01 UTC (rev 83)
@@ -0,0 +1,1786 @@
+Index: renderproto-0.9.2/library
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ renderproto-0.9.2/library	2005-12-26 22:32:38.000000000 -0500
+@@ -0,0 +1,600 @@
++                         The Xrender Library
++			    Version 0.7
++			      2002-11-6
++			    Keith Packard
++			  keithp@xfree86.org
++
++1. Introduction
++
++The Xrender library is designed as a lightweight library interface to the
++Render extension.  This document describes how the library maps to the
++protocol without duplicating the semantics described by that document.
++
++2. Data Types
++
++2.1 Primitive Types
++
++For resources represented as CARD32 or XID on the wire, Xrender exposes them
++using an 'unsigned long' type as is the norm for 32-bit data objects in an
++Xlib compatible API.
++
++	typedef unsigned long	Glyph;
++	typedef unsigned long	GlyphSet;
++	typedef unsigned long	Picture;
++	typedef unsigned long	PictFormat;
++
++Glyphs are just CARD32 objects, while GlyphSet, Picture and PictFormat
++values are XIDs.
++
++	typedef int XFixed;
++
++Fixed point numbers buck the Xlib convention by being represented as ints.
++Machines for which 'int' is smaller than 32 bits cannot support the Xrender
++library.
++
++2.2 PictFormat descriptions.
++
++The definition of a PictFormat is exposed by two data structures:
++
++	typedef struct {
++	    short   red;
++	    short   redMask;
++	    short   green;
++	    short   greenMask;
++	    short   blue;
++	    short   blueMask;
++	    short   alpha;
++	    short   alphaMask;
++	} XRenderDirectFormat;
++
++	typedef struct {
++	    PictFormat		id;
++	    int			type;
++	    int			depth;
++	    XRenderDirectFormat	direct;
++	    Colormap		colormap;
++	} XRenderPictFormat;
++
++These serve both as a description of the available formats and as patterns
++against which available formats are matched.
++
++2.3 Picture Attributes
++
++When creating or changing Picture objects, attributes are passed much as
++they are for XCreateWindow/XChangeWindowAttributes.  A structure capable of
++holding all of the attributes has the relevant ones set and a bitmask passed
++as a separate argument which marks the valid entries.
++
++	typedef struct _XRenderPictureAttributes {
++	    Bool		repeat;
++	    Picture		alpha_map;
++	    int			alpha_x_origin;
++	    int			alpha_y_origin;
++	    int			clip_x_origin;
++	    int			clip_y_origin;
++	    Pixmap		clip_mask;
++	    Bool		graphics_exposures;
++	    int			subwindow_mode;
++	    int			poly_edge;
++	    int			poly_mode;
++	    Atom		dither;
++	    Bool		component_alpha;
++	} XRenderPictureAttributes;
++
++2.4 Colors
++
++The core protocol XColor type doesn't include an alpha component, so Xrender
++has a separate type.
++
++	typedef struct {
++	    unsigned short   red;
++	    unsigned short   green;
++	    unsigned short   blue;
++	    unsigned short   alpha;
++	} XRenderColor;
++
++2.5 Glyph Types
++
++Glyphs are stored in the server, so these definitions are passed from the
++client to the library and on to the server as glyphs are rasterized and
++transmitted over the wire.
++
++	typedef struct _XGlyphInfo {
++	    unsigned short  width;
++	    unsigned short  height;
++	    short	    x;
++	    short	    y;
++	    short	    xOff;
++	    short	    yOff;
++	} XGlyphInfo;
++
++2.6 Glyph Rendering types
++
++Glyph rendering can either take a single string of glyph indices or an array
++of one of the following structures.
++
++	typedef struct _XGlyphElt8 {
++	    GlyphSet		    glyphset;
++	    _Xconst char	    *chars;
++	    int			    nchars;
++	    int			    xOff;
++	    int			    yOff;
++	} XGlyphElt8;
++	
++	typedef struct _XGlyphElt16 {
++	    GlyphSet		    glyphset;
++	    _Xconst unsigned short  *chars;
++	    int			    nchars;
++	    int			    xOff;
++	    int			    yOff;
++	} XGlyphElt16;
++	
++	typedef struct _XGlyphElt32 {
++	    GlyphSet		    glyphset;
++	    _Xconst unsigned int    *chars;
++	    int			    nchars;
++	    int			    xOff;
++	    int			    yOff;
++	} XGlyphElt32;
++	
++2.7 Geometric Types
++
++Geometric operations directly expose the available protocol datatypes
++
++	typedef struct _XPointFixed {
++	    XFixed  x, y;
++	} XPointFixed;
++	
++	typedef struct _XLineFixed {
++	    XPointFixed	p1, p2;
++	} XLineFixed;
++	
++	typedef struct _XTriangle {
++	    XPointFixed	p1, p2, p3;
++	} XTriangle;
++	
++	typedef struct _XTrapezoid {
++	    XFixed  top, bottom;
++	    XLineFixed	left, right;
++	} XTrapezoid;
++
++	typedef struct _XTransform {
++	    XFixed  matrix[3][3];
++	} XTransform;
++
++2.8 Transformation Filters
++
++All of the filters are named simultaneously; Xrender provides no convenience
++functions for dealing with them.
++
++	typedef struct _XFilters {
++	    int	    nfilter;
++	    char    **filter;
++	    int	    nalias;
++	    short   *alias;
++	} XFilters;
++
++2.9 Index type PictFormat colors
++
++PictFormats of Index type advertise which colors will be used for drawing
++through this type.
++
++	typedef struct _XIndexValue {
++	    unsigned long    pixel;
++	    unsigned short   red, green, blue, alpha;
++	} XIndexValue;
++
++
++3 Application Startup Functions
++
++3.1 Initialization functions
++
++	Bool XRenderQueryExtension (Display *dpy, 
++			            int     *event_basep, 
++				    int     *error_basep)
++
++This function returns True if the Render extension is available on dpy.
++event_basep and error_basep will be filled in with the first event and error
++numbers used by the extension (note that Render currently uses no events).
++
++	Status XRenderQueryVersion (Display *dpy,
++				    int     *major_versionp,
++				    int     *minor_versionp)
++
++XRenderQueryVersion returns zero if the Render extension is not present or
++some error occurred while attempting to discover the current Render version
++number.  Otherwise, XRenderQueryVersion returns 1 and stores the version
++number returned by the server in *major_versionp and *minor_versionp, which
++will be less than or equal to the library version numbers RENDER_MAJOR and
++RENDER_MINOR.
++
++	Status XRenderQueryFormats (Display *dpy)
++
++XRenderQueryFormats returns 1 if it successfully fetches the available
++PictFormat information from the X server, 0 otherwise.  Applications needn't
++invoke this function directly (hmm, perhaps it should be removed from the
++external interfaces then).
++
++3.2 Subpixel Order
++
++	int XRenderQuerySubpixelOrder (Display *dpy, int screen)
++
++	Bool XRenderSetSubpixelOrder (Display *dpy, int screen, int subpixel)
++
++Applications interested in the geometry of the elements making up a single
++pixel on the screen should use XRenderQuerySubpixelOrder and not cache the
++return value.  XRenderSetSubpixelOrder is used by the XRandR library to
++update the value stored by Xrender when the subpixel order changes as a
++result of screen reconfiguration.
++
++3.3 PictFormat matching
++
++Xrender provides these APIs to help locate appropriate PictFormats; they are
++intended to work much like the Visual matching APIs in Xlib.  The
++application provides a specification including the necessary PictFormat
++characteristics and Xrender returns a matching XRenderPictFormat structure
++which describes the PictFormat.
++
++	XRenderPictFormat *
++	XRenderFindFormat (Display			*dpy,
++			   unsigned long		mask,
++			   _Xconst XRenderPictFormat	*templ,
++			   int				count)
++    
++	#define PictFormatID	    (1 << 0)
++	#define PictFormatType	    (1 << 1)
++	#define PictFormatDepth	    (1 << 2)
++	#define PictFormatRed	    (1 << 3)
++	#define PictFormatRedMask   (1 << 4)
++	#define PictFormatGreen	    (1 << 5)
++	#define PictFormatGreenMask (1 << 6)
++	#define PictFormatBlue	    (1 << 7)
++	#define PictFormatBlueMask  (1 << 8)
++	#define PictFormatAlpha	    (1 << 9)
++	#define PictFormatAlphaMask (1 << 10)
++	#define PictFormatColormap  (1 << 11)
++	
++XRenderFindFormat locates a PictFormat matching the characteristics provided
++in the templ.  Only elements whose associated bit in mask are compared.
++
++	XRenderPictFormat *
++	XRenderFindVisualFormat (Display *dpy, _Xconst Visual *visual)
++
++Finds the PictFormat suitable for use with the specified visual.
++
++	XRenderPictFormat *
++	XRenderFindStandardFormat (Display		*dpy,
++				   int			format)
++
++	#define PictStandardARGB32  0
++	#define PictStandardRGB24   1
++	#define PictStandardA8	    2
++	#define PictStandardA4	    3
++	#define PictStandardA1	    4
++	#define PictStandardNUM	    5
++
++As a convenience, this function locates PictFormats that coorespond to
++commonly used formats.
++
++	ARGB32		depth 32, bits 31-24 A, 23-16 R, 15-8 G, 7-0 B
++	RGB24		depth 24, bits 23-16 R, 15-8 G, 7-0 B
++	A8		depth 8, bits 7-0 A
++	A4		depth 4, bits 3-0 A
++	A1		depth 1, bits 0 A
++
++Any server supporting Render must have a PictFormat cooresponding to each of
++these standard formats.
++
++3.4 Index type PictFormat color values
++
++	XIndexValue *
++	XRenderQueryPictIndexValues(Display			*dpy,
++				    _Xconst XRenderPictFormat	*format,
++				    int				*num)
++
++If format refers to an Index type PictFormat, XRenderQueryPictIndexValues
++returns the set of pixel values and their associated colors used when
++drawing to Pictures created with that format.  Otherwise,
++XRenderQueryPictIndexValues generates a BadMatch error.
++
++3.5 Querying available filters
++
++	XFilters *
++	XRenderQueryFilters (Display *dpy, Drawable drawable);
++
++Filters are used with non-identity transformation matrices, this function
++returns a datastructure identifying the available filters on display that
++can be associated with pictures for the screen associated with drawable.
++
++Free this structure with XFree.
++
++4 Picture Functions
++
++	Picture
++	XRenderCreatePicture (Display				*dpy,
++			      Drawable				drawable,
++			      _Xconst XRenderPictFormat		*format,
++			      unsigned long			valuemask,
++			      _Xconst XRenderPictureAttributes	*attributes)
++	
++	#define CPRepeat			    (1 << 0)
++	#define CPAlphaMap			    (1 << 1)
++	#define CPAlphaXOrigin			    (1 << 2)
++	#define CPAlphaYOrigin			    (1 << 3)
++	#define CPClipXOrigin			    (1 << 4)
++	#define CPClipYOrigin			    (1 << 5)
++	#define CPClipMask			    (1 << 6)
++	#define CPGraphicsExposure		    (1 << 7)
++	#define CPSubwindowMode			    (1 << 8)
++	#define CPPolyEdge			    (1 << 9)
++	#define CPPolyMode			    (1 << 10)
++	#define CPDither			    (1 << 11)
++	#define CPComponentAlpha		    (1 << 12)
++	#define CPLastBit			    11
++
++Creates a picture for drawable in the specified format.  Any values
++specified in 'attributes' and 'valuemask' are used in place of the default
++values.
++
++	void
++	XRenderChangePicture (Display				*dpy,
++			      Picture				picture,
++			      unsigned long			valuemask,
++			      _Xconst XRenderPictureAttributes  *attributes)
++
++Change values in picture to those specified by valuemask and attributes.
++			      
++
++	void
++	XRenderSetPictureClipRectangles (Display	    *dpy,
++					 Picture	    picture,
++					 int		    xOrigin,
++					 int		    yOrigin,
++					 _Xconst XRectangle *rects,
++					 int		    n)
++
++Sets the clip mask in picture to the union of rects offset by
++xOrigin/yOrigin.
++
++	void
++	XRenderSetPictureClipRegion (Display	    *dpy,
++				     Picture	    picture,
++				     Region	    r)
++
++Sets the clip mask in picture to r.
++
++	void
++	XRenderSetPictureTransform (Display	    *dpy,
++				    Picture	    picture,
++				    XTransform	    *transform)
++
++Sets the projective transformation matrix of picture to transform.
++
++	void
++	XRenderFreePicture (Display                   *dpy,
++			    Picture                   picture)
++	
++Instructs the server to free picture.
++
++5 GlyphSet functions
++
++	GlyphSet
++	XRenderCreateGlyphSet (Display *dpy, _Xconst XRenderPictFormat *format)
++	
++Creates a glyphset, every glyph in the set will use PictFormat format.
++
++	GlyphSet
++	XRenderReferenceGlyphSet (Display *dpy, GlyphSet existing)
++	
++Creates a new GlyphSet ID which references an existing GlyphSet.  The
++two IDs refer to the same object so that changes using one ID will be
++visible through the other ID.  This is designed to allow multiple clients to
++share the same GlyphSet so that it doesn't get destroyed when the first
++client exits.
++
++	void
++	XRenderFreeGlyphSet (Display *dpy, GlyphSet glyphset)
++	
++Frees the glyphset ID.  If no other GlyphSet IDs refer to the underlying
++GlyphSet, it will be destroyed.
++
++	void
++	XRenderAddGlyphs (Display		*dpy,
++			  GlyphSet		glyphset,
++			  _Xconst Glyph		*gids,
++			  _Xconst XGlyphInfo	*glyphs,
++			  int			nglyphs,
++			  _Xconst char		*images,
++			  int			nbyte_images)
++	
++Add glyphs to glyphset.  The images are packed together in Z-pixmap format
++according to the depth of the PictFormat used in creating glyphset.
++
++	void
++	XRenderFreeGlyphs (Display	    *dpy,
++			   GlyphSet	    glyphset,
++			   _Xconst Glyph    *gids,
++			   int		    nglyphs)
++
++Free some glyphs from glyphset.
++
++6 Glyph Drawing Routines
++
++Xrender provides two parallel APIs for glyph rendering, a simple API which
++accepts a single string similar to XDrawString and a more complex API which
++accepts an array of XGlyphElt{8,16,32} structures, each of which includes a
++glyphset, string and x/y offsets which parallel the XDrawText API.  Xrender
++also provides glyphs in three sizes, 8 16 and 32 bits.  The simple API is
++just a convenience for the user as both forms generate the same underlying
++Render protocol.
++
++6.1 Simple single-string glyph drawing functions
++
++These are identical except for the format of the glyph ids.
++
++	void
++	XRenderCompositeString8 (Display		    *dpy,
++				 int			    op,
++				 Picture		    src,
++				 Picture		    dst,
++				 _Xconst XRenderPictFormat  *maskFormat,
++				 GlyphSet		    glyphset,
++				 int			    xSrc,
++				 int			    ySrc,
++				 int			    xDst,
++				 int			    yDst,
++				 _Xconst char		    *string,
++				 int			    nchar)
++	
++	void
++	XRenderCompositeString16 (Display		    *dpy,
++				  int			    op,
++				  Picture		    src,
++				  Picture		    dst,
++				  _Xconst XRenderPictFormat *maskFormat,
++				  GlyphSet		    glyphset,
++				  int			    xSrc,
++				  int			    ySrc,
++				  int			    xDst,
++				  int			    yDst,
++				  _Xconst unsigned short    *string,
++				  int			    nchar)
++	
++	void
++	XRenderCompositeString32 (Display		    *dpy,
++				  int			    op,
++				  Picture		    src,
++				  Picture		    dst,
++				  _Xconst XRenderPictFormat *maskFormat,
++				  GlyphSet		    glyphset,
++				  int			    xSrc,
++				  int			    ySrc,
++				  int			    xDst,
++				  int			    yDst,
++				  _Xconst unsigned int	    *string,
++				  int			    nchar)
++	
++6.2 Complete glyph drawing functions 
++
++As with the simple functions above, these differ only in the type of the
++underlying glyph id storage type.
++
++	void
++	XRenderCompositeText8 (Display			    *dpy,
++			       int			    op,
++			       Picture			    src,
++			       Picture			    dst,
++			       _Xconst XRenderPictFormat    *maskFormat,
++			       int			    xSrc,
++			       int			    ySrc,
++			       int			    xDst,
++			       int			    yDst,
++			       _Xconst XGlyphElt8	    *elts,
++			       int			    nelt)
++	
++	void
++	XRenderCompositeText16 (Display			    *dpy,
++				int			    op,
++				Picture			    src,
++				Picture			    dst,
++				_Xconst XRenderPictFormat   *maskFormat,
++				int			    xSrc,
++				int			    ySrc,
++				int			    xDst,
++				int			    yDst,
++				_Xconst XGlyphElt16	    *elts,
++				int			    nelt)
++	
++	void
++	XRenderCompositeText32 (Display			    *dpy,
++				int			    op,
++				Picture			    src,
++				Picture			    dst,
++				_Xconst XRenderPictFormat   *maskFormat,
++				int			    xSrc,
++				int			    ySrc,
++				int			    xDst,
++				int			    yDst,
++				_Xconst XGlyphElt32	    *elts,
++				int			    nelt)
++	
++7 Basic Graphics Functions
++
++These are the simplest graphics functions upon which the other functions are
++conceptually built.
++
++7.1 Composite
++
++XRenderComposite exposes the RenderComposite protocol request directly.
++
++	void
++	XRenderComposite (Display   *dpy,
++			  int	    op,
++			  Picture   src,
++			  Picture   mask,
++			  Picture   dst,
++			  int	    src_x,
++			  int	    src_y,
++			  int	    mask_x,
++			  int	    mask_y,
++			  int	    dst_x,
++			  int	    dst_y,
++			  unsigned int	width,
++			  unsigned int	height)
++	
++
++7.2 Rectangles
++
++These functions composite rectangles of the specified color, they differ
++only in that XRenderFillRectangles draws more than one at a time.
++
++	void
++	XRenderFillRectangle (Display		    *dpy,
++			      int		    op,
++			      Picture		    dst,
++			      _Xconst XRenderColor  *color,
++			      int		    x,
++			      int		    y,
++			      unsigned int	    width,
++			      unsigned int	    height)
++	
++	void
++	XRenderFillRectangles (Display		    *dpy,
++			       int		    op,
++			       Picture		    dst,
++			       _Xconst XRenderColor *color,
++			       _Xconst XRectangle   *rectangles,
++			       int		    n_rects)
++	
++8 Geometric Objects
++
++All geometric drawing with Render is performed with sequences of trapezoids
++or triangles; the client is responsible for breaking more complex figures
++into these simple shapes.
++
++8.1 Trapezoids
++
++	void
++	XRenderCompositeTrapezoids (Display		*dpy,
++				    int			op,
++				    Picture		src,
++				    Picture		dst,
++				    _Xconst XRenderPictFormat	*maskFormat,
++				    int			xSrc,
++				    int			ySrc,
++				    _Xconst XTrapezoid	*traps,
++				    int			ntrap)
++
++XRenderCompositeTrapezoids builds RenderTrapezoids requests to composite the
++specified list of trapezoids to dst.  XRenderCompositeTrapezoids will split
++the list of trapezoids to build requests no larger than the maximum request
++size supported by the server.  This can create rendering artifacts as the
++precompositing done by RenderTrapezoids when a maskFormat is specified
++cannot span multiple requests.
++
++8.2 Triangles
++
++Render provides three different ways of encoding triangles on the wire,
++Xrender exposes those with three separate triangle drawing routines.  As
++with trapezoids above, Xrender will split the arguments to fit requests into
++the servers limits, but this may cause rendering artifacts.
+Index: renderproto-0.9.2/protocol
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ renderproto-0.9.2/protocol	2005-12-26 22:32:51.000000000 -0500
+@@ -0,0 +1,1176 @@
++			The X Rendering Extension
++			      Version 0.9
++			        2004-7-23
++			      Keith Packard
++			    keithp@keithp.com
++
++1. Introduction
++
++The X Rendering Extension (Render) introduces digital image composition as
++the foundation of a new rendering model within the X Window System.
++Rendering geometric figures is accomplished by client-side tesselation into
++either triangles or trapezoids.  Text is drawn by loading glyphs into the
++server and rendering sets of them.
++
++2. Acknowledgments
++
++This extension was the work of many people, in particular:
++
++ +	Thomas Porter and Tom Duff for their formal description
++	of image compositing.
++
++ +	Rob Pike and Russ Cox who designed the Plan 9 window system from
++	which the compositing model was lifted.
++
++ +	Juliusz Chroboczek and Raph Levien whose proposal for client-side
++	glyph management eliminated font handling from the X server.
++
++ +	Jon Leech, Brad Grantham and Allen Akin for patiently explaining
++	how OpenGL works.
++
++ +	Carl Worth for providing the sample implementation of
++ 	trapezoid rendering and showing how broken the spec was
++
++ +	Sam Pottle and Jamey Sharp for helping demonstrate the correctness
++ 	of the trapezoid specification.
++
++ +	Owen Taylor for helping specify projective transformations
++
++3. Rendering Model
++
++Render provides a single rendering operation which can be used in a variety of
++ways to generate images:
++
++	dest = (source IN mask) OP dest
++
++Where 'IN' is the Porter/Duff operator of that name and 'OP' is any of the
++list of compositing operators described below, among which can be found all
++of the Porter/Duff binary operators.
++
++To use this operator several additional values are required:
++
++ +	The destination rectangle.  This is a subset of the destination
++ 	within which the rendering is performed.
++
++ +	The source location. This identifies the coordinate in the
++ 	source aligned with the upper left corner of the
++	destination rectangle.
++
++ +	The mask location. This identifies the coordinate in the
++ 	mask aligned with the upper left corner of the
++	destination rectangle.
++
++ +	A clip list.  This limits the rendering to the intersection of the
++ 	destination rectangle with this clip list.
++
++ +	The OP to use
++
++ +	Whether the source should be repeated to cover the destination
++ 	rectangle, extended with a constant pixel value or extended by
++	using the nearest available source pixel.
++
++ +	Whether the mask should be repeated to cover the destination
++ 	rectangle, extended with a constant pixel value or extended by
++	using the nearest available mask pixel.
++
++ +	Whether the mask has a single alpha value for all four channels or
++ 	whether each mask channel should affect the associated source/dest
++	channels.
++
++ +	Whether the source should be reshaped with a projective
++        transformation, and if so, what filter to apply while
++	resampling the data.
++	
++ +	Whether the mask should be reshaped with a projective
++        transformation, and if so, what filter to apply while
++	resampling the data.
++	
++These parameters are variously attached to the operands or included in each
++rendering request.
++
++4. Data types
++
++The core protocol rendering system uses a pixel model and applies color only
++in the final generation of the video signal.  A compositing model operates
++on colors, not pixel values so a new datatype is needed to interpret data as
++color instead of just bits.
++
++The "PictFormat" object holds information needed to translate pixel values
++into red, green, blue and alpha channels.  The server has a list of picture
++formats corresponding to the various visuals on the screen.  There are two
++classes of formats, Indexed and Direct.  Indexed PictFormats hold a list of
++pixel values and RGBA values while Direct PictFormats hold bit masks for each
++of R, G, B and A.
++
++The "Picture" object contains a Drawable, a PictFormat and some
++rendering state.  More than one Picture can refer to the same Drawable.
++
++5. Errors
++
++Errors are sent using core X error reports.
++
++PictFormat
++	A value for a PICTFORMAT argument does not name a defined PICTFORMAT.
++
++Picture
++	A value for a PICTURE argument does not name a defined PICTURE.
++
++PictOp
++	A value for a PICTOP argument does not name a defined PICTOP.
++
++GlyphSet
++	A value for a GLYPHSET argument does not name a defined GLYPHSET.
++
++Glyph
++	A value for a GLYPH argument does not name a defined GLYPH in the
++	glyphset.
++
++6. Protocol Types
++
++PICTURE		32-bit value (top three bits guaranteed to be zero)
++PICTFORMAT	32-bit value (top three bits guaranteed to be zero)
++PICTTYPE	{ Indexed, Direct }
++PICTOP		{ Clear, Src, Dst, Over, OverReverse, In, InReverse,
++		  Out, OutReverse, Atop, AtopReverse, Xor, Add, Saturate,
++		  DisjointClear, DisjointSrc, DisjointDst, DisjointOver,
++		  DisjointOverReverse, DisjointIn, DisjointInReverse,
++		  DisjointOut, DisjointOutReverse, DisjointAtop,
++		  DisjointAtopReverse, DisjointXor,
++		  ConjointClear, ConjointSrc, ConjointDst, ConjointOver,
++		  ConjointOverReverse, ConjointIn, ConjointInReverse,
++		  ConjointOut, ConjointOutReverse, ConjointAtop,
++		  ConjointAtopReverse, ConjointXor }
++SUBPIXEL	{ Unknown, HorizontalRGB, HorizontalBGR, 
++		  VerticalRGB, VerticalBGR, None
++		}
++COLOR		[	
++			red, green, blue, alpha: CARD16
++		]
++CHANNELMASK	[
++			shift, mask: CARD16
++		]
++DIRECTFORMAT	[
++			red, green, blue, alpha: CHANNELMASK 
++		]
++INDEXVALUE	[ 
++			pixel: Pixel; 
++			red, green, blue, alpha: CARD16 
++		]
++PICTFORMINFO	[
++			id:		PICTFORMAT
++			type:		PICTTYPE
++			depth:		CARD8
++			direct:		DIRECTFORMAT
++			colormap:	COLORMAP or None
++		]
++
++PICTVISUAL	[
++			visual:		VISUALID or None
++			format:		PICTFORMAT
++		]
++
++PICTDEPTH	[
++			depth:		CARD8
++			visuals:	LISTofPICTVISUAL
++		]
++
++PICTSCREEN	LISTofPICTDEPTH
++
++FIXED		32-bit value (top 16 are integer portion, bottom 16 are fraction)
++TRANSFORM	[
++			p11, p12, p13:	FIXED
++			p21, p22, p23:	FIXED
++			p31, p32, p33:	FIXED
++		]
++POINTFIX	[
++			x, y: FIXED
++		]
++POLYEDGE	{ Sharp, Smooth }
++POLYMODE	{ Precise, Imprecise }
++COLORPOINT	[
++			point:		POINTFIX
++			color:		COLOR
++		]
++SPANFIX		[
++			left, right, y: FIXED
++		]
++COLORSPANFIX	[
++			left, right, y: FIXED
++			left_color:	COLOR
++			right_color:	COLOR
++QUAD		[
++			p1, p2, p3, p4:	POINTFIX
++		]
++TRIANGLE	[
++			p1, p2, p3:	POINTFIX
++		]
++LINEFIX		[
++			p1, p2:		POINTFIX
++		]
++TRAP		[
++			top, bottom:	SPANFIX
++		]
++TRAPEZOID	[
++			top, bottom:	FIXED
++			left, right:	LINEFIX
++		]
++(TRAPEZOID is deprecated)
++COLORTRIANGLE	[
++			p1, p2, p3:	COLORPOINT
++		]
++COLORTRAP	[
++			top, bottom:	COLORSPANFIX
++		]
++GLYPHSET	32-bit value (top three bits guaranteed to be zero)
++GLYPH		32-bit value
++GLYPHINFO	[
++			width, height:	CARD16
++			x, y:		INT16
++			off-x, off-y:	INT16
++		]
++PICTGLYPH	[
++			info:		GLYPHINFO
++			x, y:		INT16
++		]
++GLYPHABLE	GLYPHSET or FONTABLE
++GLYPHELT8	[
++			dx, dy:		INT16
++			glyphs:		LISTofCARD8
++		]
++GLYPHITEM8	GLYPHELT8 or GLYPHABLE
++GLYPHELT16	[
++			dx, dy:		INT16
++			glyphs:		LISTofCARD16
++		]
++GLYPHITEM16	GLYPHELT16 or GLYPHABLE
++GLYPHELT32	[
++			dx, dy:		INT16
++			glyphs:		LISTofCARD32
++		]
++GLYPHITEM32	GLYPHELT32 or GLYPHABLE
++
++ANIMCURSORELT	[
++			cursor:		CURSOR
++			delay:		CARD32
++		]
++7. Standard PictFormats
++
++The server must support a Direct PictFormat with 8 bits each of red, green,
++blue and alpha as well as a Direct PictFormat with 8 bits of red, green and
++blue and 0 bits of alpha.  The server must also support Direct PictFormats
++with 1, 4 and 8 bits of alpha and 0 bits of r, g and b.
++
++Pixel component values lie in the close range [0,1].  These values are
++encoded in a varying number of bits.  Values are encoded in a straight
++forward manner.  For a component encoded in m bits, a binary encoding b
++is equal to a component value of b/(2^m-1).
++
++A Direct PictFormat with zero bits of alpha component is declared to have
++alpha == 1 everywhere.  A Direct PictFormat with zero bits of red, green and
++blue is declared to have red, green, blue == 0 everywhere.  If any of red,
++green or blue components are of zero size, all are of zero size.  Direct
++PictFormats never have colormaps and are therefore screen independent.
++
++Indexed PictFormats never have alpha channels and the direct component is all
++zeros.  Indexed PictFormats always have a colormap in which the specified
++colors are allocated read-only and are therefore screen dependent.  Drawing
++to in Indexed Picture uses only pixel values listed by QueryPictIndexValues.
++Reading from an Indexed Picture uses red, green and blue values from the
++colormap and alpha values from those listed by QueryPictIndexValues.  Pixel
++values not present in QueryPictIndexValues are given alpha values of 1.
++
++8. Compositing Operators
++
++For each pixel, the four channels of the image are computed with:
++
++	C = Ca * Fa + Cb * Fb
++
++where C, Ca, Cb are the values of the respective channels and Fa and Fb
++come from the following table:
++
++	PictOp			Fa			Fb
++	--------------------------------------------------
++	Clear			0			0
++	Src			1			0
++	Dst			0			1
++	Over			1			1-Aa
++	OverReverse		1-Ab			1
++	In			Ab			0
++	InReverse		0			Aa
++	Out			1-Ab			0
++	OutReverse		0			1-Aa
++	Atop			Ab			1-Aa
++	AtopReverse		1-Ab			Aa
++	Xor			1-Ab			1-Aa
++	Add			1			1
++	Saturate		min(1,(1-Ab)/Aa)	1
++	DisjointClear		0			0
++	DisjointSrc		1			0
++	DisjointDst		0			1
++	DisjointOver		1			min(1,(1-Aa)/Ab)
++	DisjointOverReverse	min(1,(1-Ab)/Aa)	1
++	DisjointIn		max(1-(1-Ab)/Aa,0)	0
++	DisjointInReverse	0			max(1-(1-Aa)/Ab,0)
++	DisjointOut		min(1,(1-Ab)/Aa)	0
++	DisjointOutReverse	0			min(1,(1-Aa)/Ab)
++	DisjointAtop		max(1-(1-Ab)/Aa,0)	min(1,(1-Aa)/Ab)
++	DisjointAtopReverse	min(1,(1-Ab)/Aa)	max(1-(1-Aa)/Ab,0)
++	DisjointXor		min(1,(1-Ab)/Aa)	min(1,(1-Aa)/Ab)
++	ConjointClear		0			0
++	ConjointSrc		1			0
++	ConjointDst		0			1
++	ConjointOver		1			max(1-Aa/Ab,0)
++	ConjointOverReverse	max(1-Ab/Aa,0)		1
++	ConjointIn		min(1,Ab/Aa)		0
++	ConjointInReverse	0			min(Aa/Ab,1)
++	ConjointOut		max(1-Ab/Aa,0)		0
++	ConjointOutReverse	0			max(1-Aa/Ab,0)
++	ConjointAtop		min(1,Ab/Aa)		max(1-Aa/Ab,0)
++	ConjointAtopReverse	max(1-Ab/Aa,0)		min(1,Aa/Ab)
++	ConjointXor		max(1-Ab/Aa,0)		max(1-Aa/Ab,0)
++
++Saturate and DisjointOverReverse are the same.  They match OpenGL
++compositing with FUNC_ADD, SRC_ALPHA_SATURATE, ONE, except that Render uses
++premultiplied alpha while Open GL uses non-premultiplied alpha.
++
++The result of any compositing operator is always limited to the range
++[0,1] for each component.  Components whose value would be greater than 1
++are set to 1.
++
++For operations involving division, when the divisor is zero, define the
++quotient to be positive infinity.  The result is always well defined
++because the division is surrounded with a max or min operator which will
++give a finite result.
++
++When the mask contains separate alpha values for each channel, the
++alpha value resulting from the combination of that value with the source
++alpha channel is used in the final image composition.
++
++9. Source and Mask Transformations
++
++When fetching pixels from the source or mask pictures, Render provides three
++options for pixel values which fall outside the drawable (this includes
++pixels within a window geometry obscured by other windows).
++
++ +	Transparent.  Missing values are replaced with transparent.
++ 
++ +	Nearest.  Replace missing pixels with the nearest available
++ 	pixel.  Where multiple pixels are equidistant, select
++	those with smallest Y and then smallest X coordinates
++
++ +	Tile.  Select the pixel which would appear were the
++ 	drawable tiled to enclose the missing coordinate.  If
++	the tiling doesn't cover the coordinate, use the
++	selected Constant or Nearest mode.
++
++When GraphicsExposures are selected in the destination picture, a region
++containing at least the union of all destination pixel values affected by
++data replaced as above is delivered after each compositing operation.  If
++the resulting region is empty, a NoExpose event is delivered instead.
++
++To construct the source and mask operands, the computed pixels values are
++transformed through a homogeneous matrix, filtered and then used in the
++fundemental rendering operator described above.  Each screen provides a list
++of supported filter names. There are a few required filters, and several
++required filter alias which must map to one of the available filters.
++
++10. Polygon Rasterization
++
++Render provides only two kinds of polygons, trapezoids and triangles.  To
++improve efficiency, several different wire encodings exist for each. 
++
++All trapezoids must be convex.  Rendering of concave trapezoids is unspecified
++except that the result must obey the clipping rules.
++
++Composite
++Polygons are rasterized by implicit generating an alpha mask and using that
++in the general compositing operator along with a supplied source image:
++
++	tmp = Rasterize (polygon)
++	Composite (op, dst, src, tmp)
++
++When rasterized with Sharp edges, the mask is computed with a depth of 1 so
++that all of the mask values are either 0 or 1.
++
++When rasterized with Smooth edges, the mask is generated by creating a square
++around each pixel coordinate and computing the amount of that square covered
++by the polygon.  This ignores sampling theory but it provides a precise
++definition which is close to the right answer.  This value is truncated to
++the alpha width in the fallback format before application of the compositing
++operator.
++
++Rasterization
++Alpha values are generated by point sampling the coverage of a square
++surrounding the center of each pixel by the polygon. 
++
++In Precise poly mode, the sample points are located in a regular grid.  When
++alpha depth 'e' is even, the regular grid is 2**(e/2) + 1 samples wide and
++2**(e/2) -1 samples high.  For odd alpha depth 'o', the sample grid is 2**o
++- 1 samples wide and 1 sample high.  Note that odd alpha depth usually
++occurs only at depth 1, so this misshapen sample grid has no ill effects.
++The sample grid is centered within the pixel and then each sample point is
++rounded down to a point on the sub-pixel coordinate grid.
++
++In Imprecise mode, the location of the sample points is not specified, but
++the implementation must conform to the following constraints:
++
++ +	Abutting edges must match precisely.  When specifying two polygons
++	abutting along a common edge, if that edge is specified with the
++	same coordinates in each polygon then the sum of alpha values for
++	pixels inside the union of the two polygons must be precisely one.
++
++ +	Translationally invarient.  The pixelization of the polygon must
++	be the same when either the polygon or the target drawable
++	are translated by any whole number of pixels in any direction.
++
++ +	Sharp edges are honored.  When the polygon is rasterized with Sharp
++	edges, the implicit alpha mask will contain only 1 or 0 for
++	each pixel.
++
++ +	Order independent. Two identical polygons specified with vertices
++	in different orders must generate identical results.
++
++11. Image Filtering
++
++When computing pixels from source and mask images, a filter may be applied
++to the data.  This is usually used with a non-identity transformation
++matrix, but filtering may be applied with an identity transformation.
++
++Each filter is given a unique name encoded as an ISO Latin-1 string.
++Filters may be configured with a list of fixed point values; the number of
++parameters and their interpretation is currently left to conventions passed
++outside of the protocol.  A set of standard filters are required to be
++provided:
++
++	Filter Name	Description
++
++	nearest		Nearest neighbor filtering
++	bilinear	Linear interpolation in two dimensions
++
++Additional names may be provided for any filter as aliases.  A set of
++standard alias names are required to be mapped to a provided filter so that
++applications can use the alias names without checking for availability.
++
++	Alias name	Intended interpretation
++	
++	fast		High performance, quality similar to Nearest
++	good		Reasonable performance, quality similar to Bilinear
++	best		Highest quality available, performance may not
++			be suitable for interactive use
++
++Aliases must map directly to a non-aliased filter name.
++
++There is also a set of standard filters which are not required but may be
++provided.  If they are provided, using the standard name, they must match
++the definition specified here.
++
++	Filter Name	Description
++	
++	convolution	MxN convolution filter.  The values specified
++			in SetPictureFilter are M, N and then M * N
++			filter parameters.  M and N must be integers
++			represented as fixed point numbers.
++	gaussian	Gaussian blur.  The value specified is a radius
++			in pixels (which can be fractional).  A standard
++			Gaussian 2D convolution filter will be applied.
++	binomial	Binomial blur. An approximation of a Gaussian
++			blur using binomial coefficients
++
++12. Glyph Rendering
++
++Glyphs are small alpha masks which can be stored in the X server and
++rendered by referring to them by name.  A set of glyphs can be rendered in a
++single request.  Glyphs are positioned by subtracting the x, y elements of
++the GLYPHINFO from the requested rendering position.  The next glyph
++rendering position is set to the current rendering position plus the off-x
++and off-y elements.
++
++Glyphs are stored in GlyphSets and are named within the GlyphSet with
++client-specified 32-bit numbers.
++
++Glyphs can be stored in any PictFormat supported by the server.  All glyphs
++in a GlyphSet are stored in the same format.
++
++13. Extension Initialization
++
++The client must negotiate the version of the extension before executing
++extension requests.  Behavior of the server is undefined otherwise.
++
++QueryVersion
++
++	client-major-version:		CARD32
++	client-minor-version:		CARD32
++
++	->
++
++	major-version:			CARD32
++	minor-version:			CARD32
++
++	The client sends the highest supported version to the server and
++	the server sends the highest version it supports, but no higher than
++	the requested version.  Major versions changes can introduce
++	incompatibilities in existing functionality, minor version
++	changes introduce only backward compatible changes.  It is
++	the clients responsibility to ensure that the server supports
++	a version which is compatible with its expectations.
++
++QueryPictFormats
++
++	->
++
++	fallback:	PICTFORMAT
++	formats:	LISTofPICTFORMINFO
++	screens:	LISTofPICTSCREEN
++	subpixels:	LISTofSUBPIXEL
++
++	Errors:
++		<none>
++
++	The server responds with a list of supported PictFormats and
++	a list of which PictFormat goes with each visual on each screen.
++	Every PictFormat must match a supported depth, but not every
++	PictFormat need have a matching visual.
++
++	The fallback format is used as an intermediate representation
++	in cases where there is no ideal choice.
++
++	The relationship between the red, green and blue elements making
++	up each pixel indexed by screen is returned in subpixels.
++	This list is not present in servers advertising protocol
++	versions earlier than 0.6.  This list may be shorter than
++	the number of screens, in which case the remaining screens
++	are given sub pixel order Unknown.
++
++QueryPictIndexValues
++
++	format:		PICTFORMAT
++
++	->
++
++	values:		LISTofINDEXVALUE
++
++	Errors:
++		PictFormat, Match
++
++	Returns the mapping from pixel values to RGBA values for the
++	specified Indexed PictFormat.  If 'format' does not refer to
++	an Indexed PictFormat a Match error is generated.
++
++QueryFilters
++
++	drawable:	DRAWABLE
++
++	->
++
++	filters:	LISTofSTRING8
++	aliases:	LISTofCARD16
++
++	
++14. Extension Requests
++
++CreatePicture
++
++	pid:		PICTURE
++	drawable:	DRAWABLE
++	format:		PICTFORMAT
++	value-mask:	BITMASK
++	value-list:	LISTofVALUE
++
++	Errors:
++		Alloc, Drawable, IDChoice, Match, Pixmap, Picture,
++		PictFormat, Value
++
++	This request creates a Picture object associated with the specified
++	drawable and assigns the identifier pid to it.  Pixel data in the
++	image are interpreted according to 'format'.  It is a Match error
++	to specify a format with a different depth than the drawable.  If
++	the drawable is a Window then the Red, Green and Blue masks must
++	match those in the visual for the window else a Match error is
++	generated.
++
++	The value-mask and value-list specify attributes of the picture that
++	are to be explicitly initialized.  The possible values are:
++	
++	repeat:			BOOL
++	fill-nearest:		BOOL
++	alpha-map:		PICTURE or None
++	alpha-x-origin:		INT16
++	alpha-y-origin:		INT16
++	clip-x-origin:		INT16
++	clip-y-origin:		INT16
++	clip-mask:		PIXMAP or None
++	graphics-exposures:	BOOL
++	subwindow-mode:		{ ClipByChildren, IncludeInferiors }
++	poly-edge:		POLYEDGE
++	poly-mode:		POLYMODE
++	dither:			ATOM or None
++	component-alpha:	BOOL
++	
++	When used as a source or mask operand, the repeat and fill-constant
++	values control how pixels outside the geometry of the drawable are
++	computed.
++	
++	Fill-nearest indicates that pixel values outside of the drawable
++	geometry should be replaced the nearest available pixel within the
++	drawable geometry is used.  When multiple pixels are equidistant,
++	those with smaller Y and then X values are preferred.  Otherwise,
++	missing pixels are replaced with transparent.
++
++	Repeat indicates that the drawable contents should be treated
++	as if tiled in both directions.  Pixels falling in missing
++	areas of this tile are replaced according to the fill-nearest
++	rule.
++	
++	The alpha channel of alpha-map is used in place of any alpha channel
++	contained within the drawable for all rendering operations.  The
++	alpha-mask origin is interpreted relative to the origin of drawable.
++	Rendering is additionally clipped by the geometry of alpha-map.
++	Exposures to the window do not affect the contents of alpha-map.
++	Alpha-map must refer to a picture containing a Pixmap, not a Window
++	(or a Match error results).
++
++	The clip-mask restricts reads and writes to drawable.  Only pixels
++	where the clip-mask has bits set to 1 are read or written.  Pixels
++	are not accessed outside the area covered by the clip-mask or where
++	the clip-mask has bits set to 0.  The clip-mask affects all graphics
++	requests, including sources.  The clip-mask origin is interpreted
++	relative to the origin of drawable.  If a pixmap is specified as the
++	clip-mask, it must have depth 1 and have the same root as the
++	drawable (or a Match error results).  If clip-mask is None, then
++	pixels are always drawn, regardless of the clip origin.  The
++	clip-mask can also be set with the SetPictureClipRectangles request.
++	
++	For ClipByChildren, both source and destination windows are
++	additionally clipped by all viewable InputOutput children.  For
++	IncludeInferiors , neither source nor destination window is clipped
++	by inferiors.  This will result in including subwindow contents in
++	the source and drawing through subwindow boundaries of the
++	destination.  The use of IncludeInferiors with a source or
++	destination window of one depth with mapped inferiors of differing
++	depth is not illegal, but the semantics are undefined by this
++	extension.
++
++	The graphics-exposures flag controls GraphicsExposure event
++	generation for Composite requests (and any similar requests
++	defined by additional extensions).
++
++	Poly-edge and poly-mode control the rasterization of polygons
++	as described above.
++
++	Dither selects which of the available dither patterns should
++	be used.  If dither is None, no dithering will be done.
++
++	Component-alpha indicates whether each image component is
++	intended as a separate alpha value when the picture is used
++	as a mask operand.
++
++	The default component values are
++
++		Component		Default
++		-------------------------------
++		repeat			False
++		fill-nearest:		False
++		clip-x-origin        	0
++		clip-y-origin          	0
++		clip-mask		None
++		graphics-exposures	True
++		subwindow-mode		ClipByChildren
++		poly-edge		Smooth
++		poly-mode		Precise
++		dither			None
++		component-alpha		False
++
++ChangePicture
++
++	pid:		PICTURE
++	value-mask:     BITMASK
++	value-list:     LISTofVALUE
++
++	Errors:
++		Picture, Alloc, Pixmap, PictOp, Value
++
++	The value-mask and value-list specify which attributes are to be
++	changed.  The values and restrictions are the same as for 
++	CreatePicture.
++
++SetPictureClipRectangles
++
++	picture:	PICTURE
++	clip-x-origin:	INT16
++	clip-y-origin:	INT16
++	rectangles:	LISTofRECTANGLE
++
++	Errors:
++		Alloc, Picture
++
++	This request changes clip-mask in picture to the specified list of
++	rectangles and sets the clip origin.  Input and output will be
++	clipped to remain contained within the rectangles.  The clip origin
++	is interpreted relative to the origin of the drawable associated
++	with picture.  The rectangle coordinates are interpreted relative to
++	the clip origin.  Note that the list of rectangles can be empty,
++	which effectively disables output.  This is the opposite of passing
++	None as the clip-mask in CreatePicture and ChangePicture.
++	
++	Note that output is clipped to the union of all of the rectangles
++	and that no particular ordering among the rectangles is required.
++
++SetPictureTransform
++
++	picture:	PICTURE
++	transform:	TRANSFORM
++
++	Errors:
++		Alloc, Value, Picture
++
++	This request changes the projective transformation used to
++	map coordinates when 'picture' is used as the source or
++	mask in any compositing operation.  The transform
++	maps from destination pixel geometry back to the source pixel
++	geometry.
++
++	The matrix must be invertable, else a Value error is generated.
++
++SetPictureFilter
++
++	picture:	PICTURE
++	filter:		STRING8
++	values:		LISTofFIXED
++
++	Errors:
++		Value, Match, Picture
++
++	This request sets the current filter used when picture is a source
++	or mask operand.  Filter must be one of the filters supported
++	for the screen associated with picture, else a Match error
++	is generated.  If the filter accepts additional parameters,
++	they can be provided in values, incorrect values generate Value
++	errors, too many values generate Match errors.  Too few values
++	cause the filter to assume default values for the missing
++	parameters.
++
++	When created, Pictures are set to the Nearest filter.
++
++FreePicture
++
++	pid:		PICTURE
++
++	Errors:
++		Picture
++
++	This request deletes the association between the resource ID and the
++	picture.  The picture storage will be freed when no other resource
++	references it.
++
++Composite
++
++	op:		PICTOP
++	src:		PICTURE
++	mask:		PICTURE or None
++	dst:		PICTURE
++	src-x, src-y:	INT16
++	mask-x, mask-y:	INT16
++	dst-x, dst-y:	INT16
++	width, height:	CARD16
++
++	This request combines the specified rectangle of the transformed
++	src and mask operands with the specified rectangle of dst using op
++	as the compositing operator.  The coordinates are relative their
++	respective (transformed) drawable's origin.  Rendering is clipped
++	to the geometry of the dst drawable and then to the dst clip-list.
++
++	Pixels outside the geometry of src or mask needed for this
++	computation are substituted as described in the Source and Mask
++	Transformations section above.
++	
++	If src, mask and dst are not in the same format, and one of their
++	formats can hold all without loss of precision, they are converted
++	to that format.  Alternatively, the server will convert each
++	operand to the fallback format.
++
++	If mask is None, it is replaced by a constant alpha value of 1.
++
++	When dst has graphics-exposures true, a region covering all dst
++	pixels affected by substitutions performed on src or mask pixels
++	outside their respective geometries is computed.  If that region is
++	empty, a NoExpose event is sent.  Otherwise, a sequence of
++	GraphicsExpose events are sent covering that region.
++
++FillRectangles
++
++	op:		PICTOP
++	dst:		PICTURE
++	color:		COLOR
++	rects:		LISTofRECTANGLE
++
++	This request combines color with the destination drawable in the
++	area specified by rects.  Each rectangle is combined separately;
++	overlapping areas will be rendered multiple times.  The effect is
++	equivalent to compositing with a repeating source picture filled with
++	the specified color.
++
++Trapezoids
++
++	op:		PICTOP
++	src:		PICTURE
++	src-x, src-y:   INT16
++	dst:		PICTURE
++	mask-format:	PICTFORMAT or None
++	traps:		LISTofTRAPEZOID
++
++	This request rasterizes the list of trapezoids.
++	
++	For each trap, the area between the left and right edges is filled
++	from the top to the bottom.  src-x and src-y register the pattern to
++	the floor of the top x and y coordinate of the left edge of the
++	first trapezoid, they are adjusted for subsequent trapezoids so that
++	the pattern remains globally aligned within the destination.
++
++	When mask-format is not None, trapezoids are rendered in the
++	following way with the effective mask computed in mask-format:
++
++		tmp = temporary alpha picture (in mask-format)
++		Combine (Zero, tmp, tmp, None)
++		for each trapezoid
++			Combine (Add, tmp, trapezoid, None)
++		Combine (op, dst, source, tmp)
++
++	When mask-format is None, trapezoids are rendered in the order
++	specified directly to the destination:
++
++		for each trapezoid
++			Combine (op, dst, source, trapezoid)
++
++Triangles
++
++	op:		PICTOP
++	src:		PICTURE
++	src-x, src-y:   INT16
++	dst:		PICTURE
++	mask-format:	PICTFORMAT or None
++	triangles:	LISTofTRIANGLE
++
++	This request rasterizes the list of triangles in the order they
++	occur in the list.
++
++	When mask-format is not None, triangles are rendered in the
++	following way with the effective mask computed in mask-format:
++
++		tmp = temporary alpha picture (in mask-format)
++		Combine (Zero, tmp, tmp, None)
++		for each triangle
++			Combine (Add, tmp, triangle, None)
++		Combine (op, dst, source, tmp)
++
++	When mask-format is None, triangles are rendered in the order
++	specified directly to the destination:
++
++		for each triangle
++			Combine (op, dst, source, triangle)
++
++TriStrip
++
++	op:		PICTOP
++	src:		PICTURE
++	src-x, src-y:   INT16
++	dst:		PICTURE
++	mask-format:	PICTFORMAT or None
++	points:		LISTofPOINTFIX
++
++	Triangles are formed by initially using the first three points and
++	then by eliminating the first point and appending the next point in
++	the list. If fewer than three points are provided, this request does
++	nothing.
++
++	When mask-format is not None, triangles are rendered in the
++	following way with the effective mask computed in mask-format:
++
++		tmp = temporary alpha picture (in mask-format)
++		Combine (Zero, tmp, tmp, None)
++		for each triangle
++			Combine (Add, tmp, triangle, None)
++		Combine (op, dst, source, tmp)
++
++	When mask-format is None, triangles are rendered in the order
++	specified directly to the destination:
++
++		for each triangle
++			Combine (op, dst, source, triangle)
++
++TriFan
++	op:		PICTOP
++	src:		PICTURE
++	src-x, src-y:   INT16
++	dst:		PICTURE
++	mask-format:	PICTFORMAT or None
++	points:		LISTofPOINTFIX
++
++	Triangles are formed by initially using the first three points and
++	then by eliminating the second point and appending the next point
++	int the list. If fewer than three points are provided, this request
++	does nothing.
++
++	When mask-format is not None, triangles are rendered in the
++	following way with the effective mask computed in mask-format:
++
++		tmp = temporary alpha picture (in mask-format)
++		Combine (Zero, tmp, tmp, None)
++		for each triangle
++			Combine (Add, tmp, triangle, None)
++		Combine (op, dst, source, tmp)
++
++	When mask-format is None, triangles are rendered in the order
++	specified directly to the destination:
++
++		for each triangle
++			Combine (op, dst, source, triangle)
++
++ColorTrapezoids
++
++	op:		PICTOP
++	dst:		PICTURE
++	trapezoids:	LISTofCOLORTRAP
++
++	The geometry of the trapezoids must meet the same requirements as
++	for the Trapezoids request.  The trapezoids are filled in the order
++	they occur in the list.
++
++ColorTriangles
++
++	op:		PICTOP
++	dst:		PICTURE
++	triangles:	LISTofCOLORTRIANGLE
++
++	The colored triangles are rasterized in the order they occur in the
++	list.
++
++???
++
++Should I included compressed triangle representations here?
++
++???
++
++CreateGlyphSet
++
++	gsid:		GLYPHSET
++	format:		PICTFORMAT
++
++	Errors:
++		Alloc, IDChoice, PictFormat, Match
++
++	This request creates a container for glyphs.  The glyphset and
++	all contained glyphs are destroyed when gsid and any other names
++	for the glyphset are freed.  Format must be a Direct format, when
++	it contains RGB values, the glyphs are composited using
++	component-alpha True, otherwise they are composited using
++	component-alpha False.
++
++ReferenceGlyphSet
++
++	gsid:		GLYPHSET
++	existing:	GLYPHSET
++
++	Errors:
++		Alloc, IDChoice, GlyphSet
++
++	This request creates an additional name for the existing glyphset.
++	The glyphset will not be freed until all references to it are
++	destroyed.
++
++FreeGlyphSet
++
++	glyphset:	GLYPHSET
++
++	Errors:
++		GlyphSet
++
++	This request frees the name for the glyphset.  When all names have
++	been freed, the glyphset and all contained glyphs are freed.
++
++AddGlyphs
++	glyphset:	GLYPHSET
++	glyphids:	LISTofCARD32
++	glyphs:		LISTofGLYPHINFO
++	data:		LISTofBYTE
++
++	Errors:
++		GlyphSet, Alloc
++
++	This request adds glyphs to glyphset.  The image for the glyphs
++	are stored with each glyph in a separate Z-format image padded to a
++	32-bit boundary.  Existing glyphs with the same names are replaced.
++
++AddGlyphsFromPicture
++
++	glyphset:	GLYPHSET
++	src:		PICTURE
++	glyphs:		LISTofPICTGLYPH
++
++	Errors:
++		GlyphSet, Alloc
++
++	This request adds glyphs to glyphset by copying them from src from
++	the locations included in glyphs.  Existing glyphs with the same
++	names are replaced.  Src may be in a different PictFormat than
++	glyphset, in which case the images are converted to the glyphset
++	format.
++	
++FreeGlyphs
++
++	glyphset:	GLYPHSET
++	glyphs:		LISTofGLYPH
++
++	Errors:
++		GlyphSet, Match
++
++	This request removes glyphs from glyphset.  Each glyph must exist
++	in glyphset (else a Match error results).
++
++CompositeGlyphs8
++CompositeGlyphs16
++CompositeGlyphs32
++
++	op:		PICTOP
++	src:		PICTURE
++	dst:		PICTURE
++	mask-format:	PICTFORMAT or None
++	glyphset:	GLYPHABLE
++	src-x, src-y:	INT16
++	dst-x, dst-y:	INT16
++	glyphcmds:	LISTofGLYPHITEM8	CompositeGlyphs8
++	glyphcmds:	LISTofGLYPHITEM16	CompositeGlyphs16
++	glyphcmds:	LISTofGLYPHITEM32	CompositeGlyphs32
++
++	Errors:
++		Picture, PictOp, PictFormat, GlyphSet, Glyph
++
++	The dst-x and dst-y coordinates are relative to the drawable's
++	origin and specify the baseline starting position (the initial glyph
++	origin).  Each glyph item is processed in turn.  A glyphset item
++	causes the glyhpset to be used for subsequent glyphs.  Switching
++	among glyphsets does not affect the next glyph origin.  A glyph
++	element delta-x and delta-y specify additional changes in the
++	position along the x and y axes before the string is drawn; the
++	deltas are always added to the glyph origin.
++
++	All contained GLYPHSETs are always transmitted most significant byte
++	first.  
++	
++	If a GlyphSet error is generated for an item, the previous items may
++	have been drawn.
++	
++	When mask-format is not None, glyphs are rendered in the following
++	way with the effective mask computed in mask-format:
++
++		tmp = temporary alpha picture
++		Combine (Zero, tmp, tmp, None)
++		for each glyph
++			Combine (Add, tmp, glyph, None)
++		Combine (op, dst, source, tmp)
++
++	When mask-format is None, glyphs are rendered in the order specified
++	directly to the destination:
++
++		for each glyph
++			Combine (op, dst, source, glyph)
++
++CreateCursor
++
++	cid:		CURSOR
++	source:		PICTURE
++	x, y:		CARD16
++
++	Errors:		Alloc, IDChoice, Match, Picture
++
++	This request creates a cursor and associates identifier cid with it.
++	The x and y coordinates define the hotspot relative to the source's
++	origin and must be a point within the source (or a Match error
++	results).  The resulting picture will nominally be drawn to the
++	screen with PictOpOver. 
++	
++	The components of the cursor may be transformed arbitrarily to meet
++	display limitations.  In particular, if the display supports only
++	two colors cursors without translucency, the cursor will be
++	transformed so that areas less than .5 alpha will be transparent,
++	else opaque, and areas darker than 50% gray will be black else white.
++
++	The source picture can be freed immediately if no further explicit
++	references to it are to be made.
++
++	Subsequent drawing in the source has an undefined effect on the
++	cursor.  The server might or might not make a copy of the picture.
++
++CreateAnimCursor
++	cid:		CURSOR
++	cursors:	LISTofANIMCURSORELT
++
++	Errors:		Alloc, IDChoice, Cursor
++
++	This request creates a cursor and associates identifier cid with it.
++	When active, the cursor image on the screen will cycle through
++	'cursors', showing each cursor in the element for the number of
++	milliseconds indicated by the 'delay' member of that element.
++
++AddTraps
++	picture:	PICTURE
++	off-x, off-y:	INT16
++	trapezoids:	LISTofTRAP
++
++	Errors:		Match
++
++	Each trap is PictOpAdd'ed to 'picture'.  'off-x', 'off-y'
++	are added to each coordinate.
++
++	'picture' must be an alpha-only picture else a 'Match' error is
++	returned.
++	
++15. Extension Versioning
++
++The Render extension was developed in parallel with the implementation to
++ensure the feasibility of various portions of the design.  As portions of
++the extension are implemented, the version number of the extension has
++changed to reflect the portions of the standard provied.  This document
++describes the intent for version 1.0 of the specification, the partial
++implementations have version numbers less than that.  Here's a list of
++what each version before 1.0 implemented:
++
++	0.0:	
++		No disjoint/conjoint operators
++		No component alpha
++		Composite
++		CreateGlyphSet
++		FreeGlyphSet
++		AddGlyphs
++		CompositeGlyphs
++
++	0.1:
++		Component alpha
++		FillRectangles
++
++	0.2:
++		Disjoint/Conjoint operators
++
++	0.3:
++		FreeGlyphs
++
++	0.4:
++		Trapezoids
++		Triangles
++		TriStrip
++		TriFan
++
++	0.5:
++		CreateCursor
++
++	0.6:
++		SetPictureTransform
++		QueryFilters
++		SetPictureFilter
++		subpixels member of QueryPictFormats
++
++	0.7:
++		QueryPictIndexValues
++	0.8:
++		CreateAnimCursor
++	0.9:
++		AddTrapezoids

Added: trunk/renderproto-0.9.2/debian/patches/series
===================================================================
--- trunk/renderproto-0.9.2/debian/patches/series	2005-12-27 03:34:33 UTC (rev 82)
+++ trunk/renderproto-0.9.2/debian/patches/series	2005-12-27 03:42:01 UTC (rev 83)
@@ -0,0 +1 @@
+001_protocol_and_library.diff

Modified: trunk/renderproto-0.9.2/debian/render-dev.install
===================================================================
--- trunk/renderproto-0.9.2/debian/render-dev.install	2005-12-27 03:34:33 UTC (rev 82)
+++ trunk/renderproto-0.9.2/debian/render-dev.install	2005-12-27 03:42:01 UTC (rev 83)
@@ -1,5 +1,5 @@
-debian/tmp/usr/share/doc/render/library usr/share/doc/render-dev
-debian/tmp/usr/share/doc/render/protocol usr/share/doc/render-dev
-debian/tmp/usr/lib/pkgconfig/render.pc usr/lib/pkgconfig
+library usr/share/doc/render-dev
+protocol usr/share/doc/render-dev
+debian/tmp/usr/lib/pkgconfig/renderproto.pc usr/lib/pkgconfig
 debian/tmp/usr/X11R6/include/X11/extensions/render.h usr/X11R6/include/X11/extensions
 debian/tmp/usr/X11R6/include/X11/extensions/renderproto.h usr/X11R6/include/X11/extensions

Modified: trunk/renderproto-0.9.2/debian/rules
===================================================================
--- trunk/renderproto-0.9.2/debian/rules	2005-12-27 03:34:33 UTC (rev 82)
+++ trunk/renderproto-0.9.2/debian/rules	2005-12-27 03:42:01 UTC (rev 83)
@@ -4,8 +4,8 @@
 
 include debian/xsfbs/xsfbs.mk
 
-configure: configure-stamp patch
-configure-stamp:
+configure: configure-stamp 
+configure-stamp: patch
 	./configure --prefix=/usr --includedir=/usr/X11R6/include
 	touch $@
 



Reply to: