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: