diff options
author | Matt Dew <marcoz@osource.org> | 2011-04-08 23:52:33 -0600 |
---|---|---|
committer | Matt Dew <marcoz@osource.org> | 2011-04-08 23:52:33 -0600 |
commit | 3a93e47dbc500f2451c7259cef54631a60807bcb (patch) | |
tree | e3e642217e52f629c486483c644635a0cb1b1548 | |
parent | 52ad67e66cf0a8fead0499816e6d2438f600e207 (diff) |
added olinks to functions
general cleanup
-rw-r--r-- | specs/bigreq.xml | 180 |
1 files changed, 88 insertions, 92 deletions
diff --git a/specs/bigreq.xml b/specs/bigreq.xml index 788aa34..077cbc9 100644 --- a/specs/bigreq.xml +++ b/specs/bigreq.xml @@ -22,34 +22,34 @@ <legalnotice> <para> -Permission is hereby granted, free of charge, to any person obtaining -a copy of this software and associated documentation files -(the "Software"), to deal in the Software without restriction, -including without limitation the rights to use, copy, modify, merge, -publish, distribute, sublicense, and/or sell copies of the Software, -and to permit persons to whom the Software is furnished to do so, +Permission is hereby granted, free of charge, to any person obtaining +a copy of this software and associated documentation files +(the "Software"), to deal in the Software without restriction, +including without limitation the rights to use, copy, modify, merge, +publish, distribute, sublicense, and/or sell copies of the Software, +and to permit persons to whom the Software is furnished to do so, subject to the following conditions: </para> <para> -The above copyright notice and this permission notice shall be included +The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. </para> <para> -THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS -OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS +OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR +IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, -ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR +ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. </para> <para> -Except as contained in this notice, the name of the X Consortium shall -not be used in advertising or otherwise to promote the sale, use or -other dealings in this Software without prior written authorization from +Except as contained in this notice, the name of the X Consortium shall +not be used in advertising or otherwise to promote the sale, use or +other dealings in this Software without prior written authorization from the X Consortium. </para> @@ -61,33 +61,34 @@ the X Consortium. <chapter id='overview'> <title>Overview</title> -<para>This extension enables the use of protocol requests that exceed 262140 +<para>This extension enables the use of protocol requests that exceed 262140 bytes in length.</para> -<para>The core protocol restricts the maximum length of a protocol request to -262140 bytes, in that it uses a 16-bit length field specifying the number of -4-byte units in the request. This is a problem in the core protocol when -joining large numbers of lines (<symbol role='Pn'>PolyLine</symbol>) or arcs -(<symbol role='Pn'>PolyArc</symbol>), since these requests cannot be broken up -into smaller requests without disturbing the rendering of the join points. It -is also much more of a problem for protocol extensions, such as the PEX -extension for 3D graphics and the XIE extension for imaging, that need to send +<para>The core protocol restricts the maximum length of a protocol request to +262140 bytes, in that it uses a 16-bit length field specifying the number of +4-byte units in the request. This is a problem in the core protocol when +joining large numbers of lines (<symbol role='Pn'>PolyLine</symbol>) or arcs +(<symbol role='Pn'>PolyArc</symbol>), since these requests cannot be broken up +into smaller requests without disturbing the rendering of the join points. It +is also much more of a problem for protocol extensions, such as the PEX +extension for 3D graphics and the XIE extension for imaging, that need to send long data lists in output commands.</para> -<para>This extension defines a mechanism for extending the length field beyond -16 bits. If the normal 16-bit length field of the protocol request is zero, -then an additional 32-bit field containing the actual length (in 4-byte units) -is inserted into the request, immediately following the 16-bit length +<para>This extension defines a mechanism for extending the length field beyond +16 bits. If the normal 16-bit length field of the protocol request is zero, +then an additional 32-bit field containing the actual length (in 4-byte units) +is inserted into the request, immediately following the 16-bit length field.</para> -<para>For example, a normal <function>PolyLine</function> encoding is:</para> +<para>For example, a normal <emphasis role='bold'>PolyLine</emphasis> encoding is:</para> -<informaltable tabstyle='encoding1' > +<table tabstyle='encoding1' width="100%"> +<title>BLAH</title> <tgroup cols='4' align='left'> - <colspec colwidth='0.5in' colname='c1'/> - <colspec colwidth='1.5in' colname='c2'/> - <colspec colwidth='1.5in' colname='c3'/> - <colspec colwidth='2.0in' colname='c4'/> + <colspec colname='c1' colwidth="0.5*"/> + <colspec colname='c2' colwidth="3.0*"/> + <colspec colname='c3' colwidth="3.0*"/> + <colspec colname='c4' colwidth="3.0*"/> <thead> <row> <entry namest="c1" nameend="c4"><function>PolyLine</function></entry> @@ -144,22 +145,16 @@ field.</para> </row> </tbody> </tgroup> -</informaltable> +</table> -<para>An extended-length <function>PolyLine</function> encoding is:</para> +<para>An extended-length <emphasis role='bold'>PolyLine</emphasis> encoding is:</para> -<informaltable > +<informaltable width="100%"> <tgroup cols='4' align='left'> -<!-- - <colspec colwidth='0.5in' colname='c1'/> - <colspec colwidth='1.5in' colname='c2'/> - <colspec colwidth='1.5in' colname='c3'/> - <colspec colwidth='2.0in' colname='c4'/> ---> - <colspec colname='c1'/> - <colspec colname='c2'/> - <colspec colname='c3'/> - <colspec colname='c4'/> + <colspec colname='c1' colwidth="0.5*" align="left"/> + <colspec colname='c2' colwidth="3.0*" align="left"/> + <colspec colname='c3' colwidth="3.0*" align="left"/> + <colspec colname='c4' colwidth="3.0*" align="left"/> <thead> <row> <entry namest="c1" nameend="c4"><emphasis role='bold'>Poly</emphasis>Line</entry> @@ -224,7 +219,7 @@ field.</para> </tgroup> </informaltable> -<para>Extended-length protocol encodings, once enabled, can be used on all +<para>Extended-length protocol encodings, once enabled, can be used on all protocol requests, including all extensions.</para> </chapter> @@ -235,14 +230,14 @@ protocol requests, including all extensions.</para> <para role='box'>→</para> -<para role='box'><emphasis remap='I'>maximum-request-length</emphasis>: +<para role='box'><emphasis remap='I'>maximum-request-length</emphasis>: CARD32</para> <para> -This request enables extended-length protocol requests for the requesting -client. It also returns the maximum length of a request, in 4-byte units, that -can be used in extended-length protocol requests. This value will always be -greater than the maximum-request-length returned in the connection setup +This request enables extended-length protocol requests for the requesting +client. It also returns the maximum length of a request, in 4-byte units, that +can be used in extended-length protocol requests. This value will always be +greater than the maximum-request-length returned in the connection setup information. </para> </chapter> @@ -257,22 +252,19 @@ information. <title>Encoding</title> <para> -Please refer to the X11 Protocol Encoding document as this document uses +Please refer to the +<olink targetdoc='x11proto' targetptr='x11proto'> +X11 Protocol Encoding</olink> document as this document uses conventions established there. </para> <para>The name of this extension is "BIG-REQUESTS".</para> -<informaltable> +<informaltable width="100%"> <tgroup cols='3' align='left'> -<!-- - <colspec colwidth='0.5in' colname='c1'/> - <colspec colwidth='0.5in' colname='c2'/> - <colspec colwidth='2.0in' colname='c3'/> ---> - <colspec colname='c1'/> - <colspec colname='c2'/> - <colspec colname='c3'/> + <colspec colname='c1' colwidth="0.5*" align="left"/> + <colspec colname='c2' colwidth="2.0*" align="left"/> + <colspec colname='c3' colwidth="2.0*" align="left"/> <thead> <row> <entry namest="c1" nameend="c3">BigReqEnable</entry> @@ -297,14 +289,9 @@ conventions established there. </tbody> </tgroup> <tgroup cols='3' align='left'> -<!-- - <colspec colwidth='0.5in' colname='c1'/> - <colspec colwidth='1.5in' colname='c2'/> - <colspec colwidth='2.0in' colname='c3'/> ---> - <colspec colname='c1'/> - <colspec colname='c2'/> - <colspec colname='c3'/> + <colspec colname='c1' colwidth="0.5*" align="left"/> + <colspec colname='c2' colwidth="3.0*" align="left"/> + <colspec colname='c3' colwidth="3.0*" align="left"/> <thead> <row> <entry namest="c1" nameend="c3">=></entry> @@ -351,43 +338,52 @@ conventions established there. <title>C language binding</title> <para> -It is desirable for core Xlib, and other extensions, to use this -extension internally when necessary. It is also desirable to make the use of -this extension as transparent as possible to the X client. For example, if -enabling of the extension were delayed until the first time it was needed, an -application that used <function>XNextRequest</function> to determine the -sequence number of a request would no longer get the correct sequence number. -As such, <function>XOpenDisplay</function> will determine if the extension is +It is desirable for core Xlib, and other extensions, to use this +extension internally when necessary. It is also desirable to make the use of +this extension as transparent as possible to the X client. For example, if +enabling of the extension were delayed until the first time it was needed, an +application that used +<olink targetdoc='libx11' targetptr='libx11'>>XNextRequest</olink> +to determine the sequence number of a request would no longer get the +correct sequence number. As such, +<function>XOpenDisplay</function> will determine if the extension is supported by the server and, if it is, enable extended-length encodings. </para> <para> -The core Xlib functions <function>XDrawLines</function>, -<function>XDrawArcs</function>, <function>XFillPolygon</function>, -<function>XChangeProperty</function>, <function>XSetClipRectangles</function>, -and <function>XSetRegion</function> are required to use extended-length -encodings when necessary, if supported by the server. Use of extended-length -encodings in other core Xlib functions (<function>XDrawPoints</function>, -<function>XDrawRectangles</function>, <function>XDrawSegments</function>. -<function>XFillArcs</function>, <function>XFillRectangles</function>, -<function>XPutImage</function> is permitted but not required; an Xlib -implementation may choose to split the data across multiple smaller requests +The core Xlib functions +<olink targetdoc='libx11' targetptr='xdrawlines'>XDrawLines</olink>, +<olink targetdoc='libx11' targetptr='xdrawarcs'>XDrawArcs</olink>, +<olink targetdoc='libx11' targetptr='xfillpolygon'>XFillPolygon</olink>, +<olink targetdoc='libx11' targetptr='xchangeproperty'>XChangeProperty</olink>, +<olink targetdoc='libx11' targetptr='xsetcliprectangles'>XSetClipRectangles</olink>, +and <olink targetdoc='libx11' targetptr='xsetregion'>XSetRegion</olink> +are required to use extended-length encodings when necessary, if supported by +the server. Use of extended-length encodings in other core Xlib functions ( +<olink targetdoc='libx11' targetptr='xdrawpoints'>XDrawPoints</olink>, +<olink targetdoc='libx11' targetptr='xdrawrectangles'>XDrawRectangles</olink>, +<olink targetdoc='libx11' targetptr='xdrawsegments'>XDrawSegments</olink>. +<olink targetdoc='libx11' targetptr='xfillarcs'>XFillArcs</olink>, +<olink targetdoc='libx11' targetptr='xfillrectangles'>XFillRectangles</olink>, +<olink targetdoc='libx11' targetptr='xputimage'>XPutImage</olink>) +is permitted but not required; an Xlib +implementation may choose to split the data across multiple smaller requests instead. </para> <para> -To permit clients to know what the maximum-request-length for +To permit clients to know what the maximum-request-length for extended-length encodings is, the following function is added to Xlib: -<funcsynopsis> +<funcsynopsis id='xextendedmaxrequestsize'> <funcprototype> <funcdef>long <function>XExtendedMaxRequestSize</function></funcdef> <paramdef>Display <parameter> *display</parameter></paramdef> </funcprototype> </funcsynopsis> -Returns zero (0) if the specified display does not support this extension, -otherwise returns the maximum-request-length (in 4-byte units) supported by the +Returns zero (0) if the specified display does not support this extension, +otherwise returns the maximum-request-length (in 4-byte units) supported by the server through the extended-length encoding. </para> </chapter> @@ -395,7 +391,7 @@ server through the extended-length encoding. <chapter id='acknowledgements'> <title>Acknowledgements</title> -<para>Clive Feather (IXI) originated the extended-length encoding used in this +<para>Clive Feather (IXI) originated the extended-length encoding used in this extension proposal.</para> </chapter> </book> |