home *** CD-ROM | disk | FTP | other *** search
/ Chip 2001 August - Disc 2 / chip_20018102_hu.iso / linux / X-4.1.0 / doc / buffer.txt < prev    next >
Text File  |  2001-06-27  |  39KB  |  1,783 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.      Extending X for Double-Buffering, Multi-Buffering,
  11.              and Stereo
  12.  
  13.              Jeffrey Friedberg
  14.             Larry Seiler
  15.              Jeff Vroom
  16.             Version 3.3
  17.               January 11, 1990
  18.  
  19. The Multi-Buffering extension described here was a draft standard of the
  20. X Consortium prior to Release 6.1.  It has been superseded by the Double Buffer
  21. Extension (DBE).  DBE is an X Consortium Standard as of Release 6.1.
  22.  
  23.  
  24. Introduction
  25.  
  26. Several proposals have been written that address some of the
  27. issues surrounding the support of double-buffered, multi-
  28. buffered, and stereo windows in the X Window System:
  29.  
  30. o    Extending X for Double-Buffering, Jeffrey Friedberg,
  31.      Larry Seiler, Randi Rost.
  32.  
  33. o    (Proposal for) Double-Buffering Extensions, Jeff Vroom.
  34.  
  35. o    An Extension to X.11 for Displays with Multiple
  36.      Buffers, David S.H. Rosenthal.
  37.  
  38. o    A Multiple Buffering/Stereo Proposal, Mark Patrick.
  39. -----------
  40. Copyright (C) 1989 Digital Equipment Corporation.
  41. Permission to use, copy, modify, and distribute
  42. this documentation for any purpose and without fee
  43. is hereby granted, provided that the above copy-
  44. right notice and this permission notice appear in
  45. all copies.  Digital Equipment Corporation makes
  46. no representations about the suitability for any
  47. purpose of the information in this document.  This
  48. documentation is provided "as is" without express
  49. or implied warranty.  This document is subject to
  50. change.
  51. Copyright (C) 1989, 1994 X Consortium
  52. Permission is hereby granted, free of charge, to
  53. any person obtaining a copy of this software and
  54. associated documentation files (the ``Software''),
  55. to deal in the Software without restriction,
  56. including without limitation the rights to use,
  57. copy, modify, merge, publish, distribute, subli-
  58. cense, and/or sell copies of the Software, and to
  59. permit persons to whom the Software is furnished
  60. to do so, subject to the following conditions:
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.                  -2-
  71.  
  72.  
  73. The authors of this proposal have tried to unify the above
  74. documents to yield a proposal that incorporates support for
  75. double-buffering, multi-buffering, and stereo in a way that
  76. is acceptable to all concerned.
  77.  
  78. Goals
  79.  
  80. Clients should be able to:
  81.  
  82. o    Associate multiple buffers with a window.
  83.  
  84. o    Paint in any buffer associated with a window.
  85.  
  86. o    Display any buffer associated with a window.
  87.  
  88. o    Display a series of buffers in a window in rapid suc-
  89.      cession to achieve a smooth animation.
  90.  
  91. o    Request simultaneous display of different buffers in
  92.      different windows.
  93.  
  94. In addition, the extension should:
  95.  
  96. o    Allow existing X applications to run unchanged.
  97.  
  98. o    Support a range of implementation methods that can cap-
  99.      italize on existing hardware features.
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106. -----------
  107. The above copyright notice and this permission
  108. notice shall be included in all copies or substan-
  109. tial portions of the Software.
  110. THE SOFTWARE IS PROVIDED ``AS IS'', WITHOUT WAR-
  111. RANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING
  112. BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABIL-
  113. ITY, FITNESS FOR A PARTICULAR PURPOSE AND NONIN-
  114. FRINGEMENT.  IN NO EVENT SHALL THE X CONSORTIUM BE
  115. LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  116. WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHER-
  117. WISE, ARISING FROM, OUT OF OR IN CONNECTION WITH
  118. THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
  119. SOFTWARE.
  120. Except as contained in this notice, the name of
  121. the X Consortium shall not be used in advertising
  122. or otherwise to promote the sale, use or other
  123. dealings in this Software without prior written
  124. authorization from the X Consortium.
  125. X Window System is a trademark of X Consortium,
  126. Inc.
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.                  -3-
  137.  
  138.  
  139. Image Buffers
  140.  
  141. Normal windows are created using the standard CreateWindow
  142. request:
  143.  
  144.      CreateWindow
  145.       parent      : WINDOW
  146.       w_id          : WINDOW
  147.       depth       : CARD8
  148.       visual      : VISUALID or CopyFromParent
  149.       x, y          : INT16
  150.       width, height   : INT16
  151.       border_width      : INT16
  152.       value_mask      : BITMASK
  153.       value_list      : LISTofVALUE
  154.  
  155.  
  156. This request allocates a set of window attributes and a
  157. buffer into which an image can be drawn.  The contents of
  158. this image buffer will be displayed when the window is
  159. mapped to the screen.
  160.  
  161. To support double-buffering and multi-buffering, we intro-
  162. duce the notion that additional image buffers can be created
  163. and bound together to form groups.  The following rules will
  164. apply:
  165.  
  166. o    All image buffers in a group will have the same visual
  167.      type, depth, and geometry (ie: width and height).
  168.  
  169. o    Only one image buffer per group can be displayed at a
  170.      time.
  171.  
  172. o    Draw operations can occur to any image buffer at any
  173.      time.
  174.  
  175. o    Window management requests (MapWindow, DestroyWindow,
  176.      ConfigureWindow, etc...)  affect all image buffers
  177.      associated with a window.
  178.  
  179. o    Appropriate resize and exposure events will be gener-
  180.      ated for every image buffer that is affected by a win-
  181.      dow management operation.
  182.  
  183. By allowing draw operations to occur on any image buffer at
  184. any time, a client could, on a multi-threaded multi-proces-
  185. sor server, simultaneously build up images for display.  To
  186. support this, each buffer must have its own resource ID.
  187. Since buffers are different than windows and pixmaps
  188. (buffers are not hierarchical and pixmaps cannot be dis-
  189. played) a new resource, Buffer, is introduced.    Furthermore,
  190. a Buffer is also a Drawable, thus draw operations may also
  191. be performed on buffers simply by passing a buffer ID to the
  192. existing pixmap/window interface.
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.                  -4-
  203.  
  204.  
  205. To allow existing X applications to work unchanged, we
  206. assume a window ID passed in a draw request, for a multi-
  207. buffered window, will be an alias for the ID of the cur-
  208. rently displayed image buffer.    Any draw requests (eq:
  209. GetImage) on the window will be relative to the displayed
  210. image buffer.
  211.  
  212. In window management requests, only a window ID will be
  213. accepted.  Requests like QueryTree, will continue to return
  214. only window ID's.  Most events will return just the window
  215. ID.  Some new events, described in a subsequent section,
  216. will return a buffer ID.
  217.  
  218. When a window has backing store the contents of the window
  219. are saved off-screen.  Likewise, when the contents of an
  220. image buffer of a multi-buffer window is saved off-screen,
  221. it is said to have backing store.  This applies to all image
  222. buffers, whether or not they are selected for display.
  223.  
  224. In some multi-buffer implementations, undisplayed buffers
  225. might be implemented using pixmaps.  Since the contents of
  226. pixmaps exist off-screen and are not affected by occlusion,
  227. these image buffers in effect have backing store.
  228.  
  229. On the other hand, both the displayed and undisplayed image
  230. buffers might be implemented using a subset of the on-screen
  231. pixels.  In this case, unless the contents of an image
  232. buffer are saved off-screen, these image buffers in effect
  233. do not have backing store.
  234.  
  235. Output to any image buffer of an unmapped multi-buffered
  236. window that does not have backing store is discarded.  Out-
  237. put to any image buffer of a mapped multi-buffer window will
  238. be performed; however, portions of an image buffer may be
  239. occluded or clipped.
  240.  
  241. When an unmapped multi-buffered window becomes mapped, the
  242. contents of any image buffer buffer that did not have back-
  243. ing store is tiled with the background and zero or more
  244. exposure events are generated.    If no background is defined
  245. for the window, then the screen contents are not altered and
  246. the contents of any undisplayed image buffers are undefined.
  247. If backing store was maintained for an image buffer, then no
  248. exposure events are generated.
  249.  
  250. New Requests
  251.  
  252. The new request, CreateImageBuffers, creates a group of
  253. image buffers and associates them with a normal X window:
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.                  -5-
  269.  
  270.  
  271.      CreateImageBuffers
  272.       w_id         : WINDOW
  273.       buffers     : LISTofBUFFER
  274.       update_action  : {Undefined,Background,Untouched,Copied}
  275.       update_hint     : {Frequent,Intermittent,Static}
  276.       =>
  277.       number_buffers : CARD16
  278.  
  279.       (Errors: Window, IDChoice, Value)
  280.  
  281. One image buffer will be associated with each ID passed in
  282. buffers.  The first buffer of the list is referred to as
  283. buffer[0], the next buffer[1], and so on.  Each buffer will
  284. have the same visual type and geometry as the window.
  285. Buffer[0] will refer to the image buffer already associated
  286. with the window ID and its contents will not be modified.
  287. The displayed image buffer attribute is set to buffer[0].
  288.  
  289. Image buffers for the remaining ID's (buffer[1],...) are
  290. allocated.  If the window is mapped, or if these image
  291. buffers have backing store, their contents will be tiled
  292. with the window background (if no background is defined, the
  293. buffer contents are undefined), and zero or more expose
  294. events will be generated for each of these buffers.  The
  295. contents of an image buffer is undefined when the window is
  296. unmapped and the buffer does not have backing store.
  297.  
  298. If the window already has a group of image buffers associ-
  299. ated with it (ie: from a previous CreateImageBuffers
  300. request) the actions described for DestroyImageBuffers are
  301. performed first (this will delete the association of the
  302. previous buffer ID's and their buffers as well as de-allo-
  303. cate all buffers except for the one already associated with
  304. the window ID).
  305.  
  306. To allow a server implementation to efficiently allocate the
  307. buffers, the total number of buffers required and the update
  308. action (how they will behave during an update) is specified
  309. "up front" in the request.  If the server cannot allocate
  310. all the buffers requested, the total number of buffers actu-
  311. ally allocated will be returned.  No Alloc errors will be
  312. generated - buffer[0] can always be associated with the
  313. existing displayed image buffer.
  314.  
  315. For example, an application that wants to animate a short
  316. movie loop may request 64 image buffers.  The server may
  317. only be able to support 16 image buffers of this type, size,
  318. and depth.  The application can then decide 16 buffers is
  319. sufficient and may truncate the movie loop, or it may decide
  320. it really needs 64 and will free the buffers and complain to
  321. the user.
  322.  
  323. One might be tempted to provide a request that inquires
  324. whether n buffers of a particular type, size, and depth
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.                  -6-
  335.  
  336.  
  337. could be allocated.  But if the query is decoupled from the
  338. actual allocation, another client could sneak in and take
  339. the buffers before the original client has allocated them.
  340.  
  341. While any buffer of a group can be selected for display,
  342. some applications may display buffers in a predictable order
  343. (ie: the movie loop application).  The list order
  344. (buffer[0], buffer[1], ...) will be used as a hint by the
  345. server as to which buffer will be displayed next.  A client
  346. displaying buffers in this order may see a performance
  347. improvement.
  348.  
  349. update_action indicates what should happen to a previously
  350. displayed buffer when a different buffer becomes displayed.
  351. Possible actions are:
  352.  
  353. Undefined      The contents of the buffer that was last dis-
  354.            played will become undefined after the
  355.            update.    This is the most efficient action
  356.            since it allows the implementation to trash
  357.            the contents of the buffer if it needs to.
  358.  
  359. Background     The contents of the buffer that was last dis-
  360.            played will be set to the background of the
  361.            window after the update.  The background
  362.            action allows devices to use a fast clear
  363.            capability during an update.
  364.  
  365. Untouched      The contents of the buffer that was last dis-
  366.            played will be untouched after the update.
  367.            Used primarily when cycling through images
  368.            that have already been drawn.
  369.  
  370. Copied           The contents of the buffer that was last dis-
  371.            played will become the same as those that are
  372.            being displayed after the update.  This is
  373.            useful when incrementally adding to an image.
  374.  
  375. update_hint indicates how often the client will request a
  376. different buffer to be displayed.  This hint will allow
  377. smart server implementations to choose the most efficient
  378. means to support a multi-buffered window based on the cur-
  379. rent need of the application (dumb implementations may
  380. choose to ignore this hint).  Possible hints are:
  381.  
  382. Frequent       An animation or movie loop is being attempted
  383.            and the fastest, most efficient means for
  384.            multi-buffering should be employed.
  385.  
  386. Intermittent   The displayed image will be changed every so
  387.            often.  This is common for images that are
  388.            displayed at a rate slower than a second.
  389.            For example, a clock that is updated only
  390.            once a minute.
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.                  -7-
  401.  
  402.  
  403. Static           The displayed image buffer will not be
  404.            changed any time soon.  Typically set by an
  405.            application whenever there is a pause in the
  406.            animation.
  407.  
  408. To display an image buffer the following request can be
  409. used:
  410.  
  411.      DisplayImageBuffers
  412.       buffers      : LISTofBUFFER
  413.       min_delay      : CARD16
  414.       max_delay      : CARD16
  415.  
  416.       (Errors: Buffer, Match)
  417.  
  418. The image buffers listed will become displayed as simultane-
  419. ously as possible and the update action, bound at CreateIm-
  420. ageBuffers time, will be performed.
  421.  
  422. A list of buffers is specified to allow the server to effi-
  423. ciently change the display of more than one window at a time
  424. (ie: when a global screen swap method is used).  Attempting
  425. to simultaneously display multiple image buffers from the
  426. same window is an error (Match) since it violates the rule
  427. that only one image buffer per group can be displayed at a
  428. time.
  429.  
  430. If a specified buffer is already displayed, any delays and
  431. update action will still be performed for that buffer.    In
  432. this instance, only the update action of Background (and
  433. possibly Undefined) will have any affect on the contents of
  434. the displayed buffer.  These semantics allow an animation
  435. application to successfully execute even when there is only
  436. a single buffer available for a window.
  437.  
  438. When a DisplayImageBuffers request is made to an unmapped
  439. multi-buffered window, the effect of the update action
  440. depends on whether the image buffers involved have backing
  441. store.    When the target of the update action is an image
  442. buffer that does not have backing store, output is dis-
  443. carded.  When the target image buffer does have backing
  444. store, the update is performed; however, when the source of
  445. the update is an image buffer does not have backing store
  446. (as in the case of update action Copied), the contents of
  447. target image buffer will become undefined.
  448.  
  449. min_delay and max_delay put a bound on how long the server
  450. should wait before processing the display request.  For each
  451. of the windows to be updated by this request, at least
  452. min_delay milli-seconds should elapse since the last time
  453. any of the windows were updated; conversely, no window
  454. should have to wait more than max_delay milli-seconds before
  455. being updated.
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.                  -8-
  467.  
  468.  
  469. min_delay allows an application to slow down an animation or
  470. movie loop so that it appears synchronized at a rate the
  471. server can support given the current load.  For example, a
  472. min_delay of 100 indicates the server should wait at least
  473. 1/10 of a second since the last time any of the windows were
  474. updated.  A min_delay of zero indicates no waiting is neces-
  475. sary.
  476.  
  477. max_delay can be thought of as an additional delay beyond
  478. min_delay the server is allowed to wait to facilitate such
  479. things as efficient update of multiple windows.  If
  480. max_delay would require an update before min_delay is satis-
  481. fied, then the server should process the display request as
  482. soon as the min_delay requirement is met.  A typical value
  483. for max_delay is zero.
  484.  
  485. To implement the above functionality, the time since the
  486. last update by a DisplayImageBuffers request for each multi-
  487. buffered window needs to be saved as state by the server.
  488. The server may delay execution of the DisplayImageBuffers
  489. request until the appropriate time (e.g. by requeuing the
  490. request after computing the timeout); however, the entire
  491. request must be processed in one operation.  Request execu-
  492. tion indivisibility must be maintained.  When a server is
  493. implemented with internal concurrency, the extension must
  494. adhere to the same concurrency semantics as those defined
  495. for the core protocol.
  496.  
  497. To explicitly clear a rectangular area of an image buffer to
  498. the window background, the following request can be used:
  499.  
  500.      ClearImageBufferArea
  501.       buffer      : BUFFER
  502.       x, y          : INT16
  503.       w, h          : CARD16
  504.       exposures      : BOOL
  505.  
  506.       (Errors: Buffer, Value)
  507.  
  508.  
  509. Like the X ClearArea request, x and y are relative to the
  510. window's origin and specify the upper-left corner of the
  511. rectangle.  If width is zero, it is replaced with the cur-
  512. rent window width minus x.  If height is zero it is replaced
  513. with the current window height minus y.  If the window has a
  514. defined background tile, the rectangle is tiled with a plane
  515. mask of all ones, a function of Copy, and a subwindow-mode
  516. of ClipByChildren.  If the window has background None, the
  517. contents of the buffer are not changed.  In either case, if
  518. exposures is true, then one or more exposure events are gen-
  519. erated for regions of the rectangle that are either visible
  520. or are being retained in backing store.
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.                  -9-
  533.  
  534.  
  535. The group of image buffers allocated by a CreateImageBuffers
  536. request can be destroyed with the following request:
  537.  
  538.      DestroyImageBuffers
  539.       w_id        : WINDOW
  540.  
  541.       (Error: Window)
  542.  
  543.  
  544. The association between the buffer ID's and their corre-
  545. sponding image buffers are deleted.  Any image buffers not
  546. selected for display are de-allocated.    If the window is not
  547. multi-buffered, the request is ignored.
  548.  
  549. Attributes
  550.  
  551. The following attributes will be associated with each window
  552. that is multi-buffered:
  553.  
  554.       displayed_buffer : CARD16
  555.       update_action    : {Undefined,Background,Untouched,Copied}
  556.       update_hint       : {Frequent,Intermittent,Static}
  557.       window_mode       : {Mono,Stereo}
  558.       buffers       : LISTofBUFFER
  559.  
  560.  
  561. displayed_buffer is set to the index of the currently dis-
  562. played image buffer (for stereo windows, this will be the
  563. index of the left buffer - the index of the right buffer is
  564. simply index+1).  window_mode indicates whether this window
  565. is Mono or Stereo.  The ID for each buffer associated with
  566. the window is recorded in the buffers list.  The above
  567. attributes can be queried with the following request:
  568.  
  569.      GetMultiBufferAttributes
  570.       w_id           : WINDOW
  571.       =>
  572.       displayed_buffer : CARD16
  573.       update_action    : {Undefined,Background,Untouched,Copied}
  574.       update_hint       : {Frequent,Intermittent,Static}
  575.       window_mode       : {Mono,Stereo}
  576.       buffers       : LISTofBUFFER
  577.  
  578.       (Errors: Window, Access, Value)
  579.  
  580.  
  581. If the window is not multi-buffered, a Access error will be
  582. generated.  The only multi-buffer attribute that can be
  583. explicitly set is update_hint.    Rather than have a specific
  584. request to set this attribute, a generic set request is pro-
  585. vided to allow for future expansion:
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.                 -10-
  599.  
  600.  
  601.      SetMultiBufferAttributes
  602.       w_id          : WINDOW
  603.       value_mask      : BITMASK
  604.       value_list      : LISTofVALUE
  605.  
  606.       (Errors: Window, Match, Value)
  607.  
  608.  
  609. If the window is not multi-buffered, a Match error will be
  610. generated.  The following attributes are maintained for each
  611. buffer of a multi-buffered window:
  612.  
  613.       window       : WINDOW
  614.       event_mask       : SETofEVENT
  615.       index        : CARD16
  616.       side           : {Mono,Left,Right}
  617.  
  618.  
  619. window indicates the window this buffer is associated with.
  620. event_mask specifies which events, relevant to buffers, will
  621. be sent back to the client via the associated buffer ID
  622. (initially no events are selected).  index is the list posi-
  623. tion (0, 1, ...) of the buffer.  side indicates whether this
  624. buffer is associated with the left side or right side of a
  625. stereo window.    For non-stereo windows, this attribute will
  626. be set to Mono.  These attributes can be queried with the
  627. following request:
  628.  
  629.      GetBufferAttributes
  630.       buffer      : BUFFER
  631.       =>
  632.       window       : WINDOW
  633.       event_mask       : SETofEVENT
  634.       index        : CARD16
  635.       side           : {Mono,Left,Right}
  636.  
  637.       (Errors: Buffer, Value)
  638.  
  639.  
  640. The only buffer attribute that can be explicitly set is
  641. event_mask.  The only events that are valid are Expose and
  642. the new ClobberNotify and UpdateNotify event (see Events
  643. section below).  A Value error will be generated if an event
  644. not selectable for a buffer is specified in an event mask.
  645. Rather than have a specific request to set this attribute, a
  646. generic set request is provided to allow for future expan-
  647. sion:
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.                 -11-
  665.  
  666.  
  667.      SetBufferAttributes
  668.       buffer      : BUFFER
  669.       value_mask      : BITMASK
  670.       value_list      : LISTofVALUE
  671.  
  672.       (Errors: Buffer, Value)
  673.  
  674.  
  675. Clients may want to query the server about basic multi-
  676. buffer and stereo capability on a per screen basis.  The
  677. following request returns a large list of information that
  678. would most likely be read once by Xlib for each screen, and
  679. used as a data base for other Xlib queries:
  680.  
  681.      GetBufferInfo
  682.       root          : WINDOW
  683.       =>
  684.       info          : LISTofSCREEN_INFO
  685.  
  686.  
  687. Where SCREEN_INFO and BUFFER_INFO are defined as:
  688.  
  689.  
  690.       SCREEN_INFO      : [ normal_info : LISTofBUFFER_INFO,
  691.                   stereo_info : LISTofBUFFER_INFO ]
  692.  
  693.       BUFFER_INFO      : [ visual      : VISUALID,
  694.                   max_buffers : CARD16,
  695.                   depth      : CARD8 ]
  696.  
  697.  
  698. Information regarding multi-buffering of normal (mono) win-
  699. dows is returned in the normal_info list.  The stereo_info
  700. list contains information about stereo windows.  If the
  701. stereo_info list is empty, stereo windows are not supported
  702. on the screen.    If max_buffers is zero, the maximum number
  703. of buffers for the depth and visual is a function of the
  704. size of the created window and current memory limitations.
  705.  
  706. The following request returns the major and minor version
  707. numbers of this extension:
  708.  
  709.      GetBufferVersion
  710.       =>
  711.       major_number      : CARD8
  712.       minor_number      : CARD8
  713.  
  714.  
  715. The version numbers are an escape hatch in case future revi-
  716. sions of the protocol are necessary.  In general, the major
  717. version would increment for incompatible changes, and the
  718. minor version would increment for small upward compatible
  719. changes.  Barring changes, the major version will be 1, and
  720. the minor version will be 1.
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.                 -12-
  731.  
  732.  
  733. Events
  734.  
  735. All events normally generated for single-buffered windows
  736. are also generated for multi-buffered windows.    Most of
  737. these events (ie: ConfigureNotify) will only be generated
  738. for the window and not for each buffer.  These events will
  739. return a window ID.
  740.  
  741. Expose events will be generated for both the window and any
  742. buffer affected.  When this event is generated for a buffer,
  743. the same event structure will be used but a buffer ID is
  744. returned instead of a window ID.  Clients, when processing
  745. these events, will know whether an ID returned in an event
  746. structure is for a window or a buffer by comparing the
  747. returned ID to the ones returned when the window and buffer
  748. were created.
  749.  
  750. GraphicsExposure and NoExposure are generated using whatever
  751. ID is specified in the graphics operation.  If a window ID
  752. is specified, the event will contain the window ID.  If a
  753. buffer ID is specified, the event will contain the buffer
  754. ID.
  755.  
  756. In some implementations, moving a window over a multi-
  757. buffered window may cause one or more of its buffers to get
  758. overwritten or become unwritable.  To allow a client drawing
  759. into one of these buffers the opportunity to stop drawing
  760. until some portion of the buffer is writable, the following
  761. event is added:
  762.  
  763.      ClobberNotify
  764.       buffer     :  BUFFER
  765.       state      : {Unclobbered,PartiallyClobbered,FullyClobbered}
  766.  
  767.  
  768. The ClobberNotify event is reported to clients selecting
  769. ClobberNotify on a buffer.  When a buffer that was fully or
  770. partially clobbered becomes unclobbered, an event with
  771. Unclobbered is generated.  When a buffer that was unclob-
  772. bered becomes partially clobbered, an event with Partially-
  773. Clobbered is generated.  When a buffer that was unclobbered
  774. or partially clobbered becomes fully clobbered, an event
  775. with FullyClobbered is generated.
  776.  
  777. ClobberNotify events on a given buffer are generated before
  778. any Expose events on that buffer, but it is not required
  779. that all ClobberNotify events on all buffers be generated
  780. before all Expose events on all buffers.
  781.  
  782. The ordering of ClobberNotify events with respect to Visi-
  783. bilityNotify events is not constrained.
  784.  
  785. If multiple buffers were used as an image FIFO between an
  786. image server and the X display server, then the FIFO manager
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.                 -13-
  797.  
  798.  
  799. would like to know when a buffer that was previously dis-
  800. played, has been undisplayed and updated, as the side effect
  801. of a DisplayImageBuffers request.  This allows the FIFO man-
  802. ager to load up a future frame as soon as a buffer becomes
  803. available.  To support this, the following event is added:
  804.  
  805.      UpdateNotify
  806.       buffer     :  BUFFER
  807.  
  808.  
  809. The UpdateNotify event is reported to clients selecting
  810. UpdateNotify on a buffer.  Whenever a buffer becomes updated
  811. (e.g. its update action is performed as part of a DisplayIm-
  812. ageBuffers request), an UpdateNotify event is generated.
  813.  
  814. Errors
  815.  
  816. The following error type has been added to support this
  817. extension:
  818.  
  819. Buffer           A value for a BUFFER argument does not name a
  820.            defined BUFFER.
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842.  
  843.  
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853.  
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.                 -14-
  863.  
  864.  
  865. Double-Buffering Normal Windows
  866.  
  867. The following pseudo-code fragment illustrates how to create
  868. and display a double-buffered image:
  869.  
  870.      /*
  871.       * Create a normal window
  872.       */
  873.      CreateWindow( W, ... )
  874.  
  875.      /*
  876.       * Create two image buffers.  Assume after display, buffer
  877.       * contents become "undefined".  Assume we will "frequently"
  878.       * update the display.  Abort if we don't get two buffers,
  879.       */
  880.      n = CreateImageBuffers( W, [B0,B1], Undefined, Frequent )
  881.      if (n != 2) <abort>
  882.  
  883.      /*
  884.       * Map window to the screen
  885.       */
  886.      MapWindow( W )
  887.  
  888.      /*
  889.       * Draw images using alternate buffers, display every
  890.       * 1/10 of a second.  Note we draw B1 first so it will
  891.       * "pop" on the screen
  892.       */
  893.      while animating
  894.      {
  895.       <draw picture using B1>
  896.       DisplayImageBuffers( [B1], 100, 0 )
  897.  
  898.       <draw picture using B0>
  899.       DisplayImageBuffers( [B0], 100, 0 )
  900.      }
  901.  
  902.      /*
  903.       * Strip image buffers and leave window with
  904.       * contents of last displayed image buffer.
  905.       */
  906.      DestroyImageBuffers( W )
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.                 -15-
  929.  
  930.  
  931. Multi-Buffering Normal Windows
  932.  
  933. Multi-buffered images are also supported by these requests.
  934. The following pseudo-code fragment illustrates how to create
  935. a a multi-buffered image and cycle through the images to
  936. simulate a movie loop:
  937.  
  938.      /*
  939.       * Create a normal window
  940.       */
  941.      CreateWindow( W, ... )
  942.  
  943.      /*
  944.       * Create 'N' image buffers.  Assume after display, buffer
  945.       * contents are "untouched".  Assume we will "frequently"
  946.       * update the display.  Abort if we don't get all the buffers.
  947.       */
  948.      n = CreateImageBuffers( W, [B0,B1,...,B(N-1)], Untouched, Frequent )
  949.      if (n != N) <abort>
  950.  
  951.      /*
  952.       * Map window to screen
  953.       */
  954.      MapWindow( W )
  955.  
  956.      /*
  957.       * Draw each frame of movie one per buffer
  958.       */
  959.      foreach frame
  960.       <draw frame using B(i)>
  961.  
  962.      /*
  963.       * Cycle through frames, one frame every 1/10 of a second.
  964.       */
  965.      while animating
  966.      {
  967.       foreach frame
  968.            DisplayImageBuffers( [B(i)], 100, 0 )
  969.      }
  970.  
  971.  
  972.  
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.                 -16-
  995.  
  996.  
  997. Stereo Windows
  998.  
  999. How stereo windows are supported on a server is implementa-
  1000. tion dependent.  A server may contain specialized hardware
  1001. that allows left and right images to be toggled at field or
  1002. frame rates.  The stereo affect may only be perceived with
  1003. the aid of special viewing glasses.  The display of a stereo
  1004. picture should be independent of how often the contents of
  1005. the picture are updated by an application.  Double and
  1006. multi-buffering of images should be possible regardless of
  1007. whether the image is displayed normally or in stereo.
  1008.  
  1009. To achieve this goal, a simple extension to normal windows
  1010. is suggested.  Stereo windows are just like normal windows
  1011. except the displayed image is made up of a left image buffer
  1012. and a right image buffer.  To create a stereo window, a
  1013. client makes the following request:
  1014.  
  1015.      CreateStereoWindow
  1016.       parent      : WINDOW
  1017.       w_id          : WINDOW
  1018.       left, right      : BUFFER
  1019.       depth       : CARD8
  1020.       visual      : VISUALID or CopyFromParent
  1021.       x, y          : INT16
  1022.       width, height   : INT16
  1023.       border_width      : INT16
  1024.       value_mask      : BITMASK
  1025.       value_list      : LISTofVALUE
  1026.  
  1027.       (Errors: Alloc, Color, Cursor, Match,
  1028.            Pixmap, Value, Window)
  1029.  
  1030.  
  1031. This request, modeled after the CreateWindow request, adds
  1032. just two new parameters: left and right.  For stereo, it is
  1033. essential that one can distinguish whether a draw operation
  1034. is to occur on the left image or right image.  While an
  1035. internal mode could have been added to achieve this, using
  1036. two buffer ID's allows clients to simultaneously build up
  1037. the left and right components of a stereo image.  These ID's
  1038. always refer to (are an alias for) the left and right image
  1039. buffers that are currently displayed.
  1040.  
  1041. Like normal windows, the window ID is used whenever a window
  1042. management operation is to be performed.  Window queries
  1043. would also return this window ID (eg: QueryTree) as would
  1044. most events.  Like the window ID, the left and right buffer
  1045. ID's each have their own event mask.  They can be set and
  1046. queried using the Set/GetBufferAttributes requests.
  1047.  
  1048. Using the window ID of a stereo window in a draw request
  1049. (eg: GetImage) results in pixels that are undefined.  Possi-
  1050. ble semantics are that both left and right images get drawn,
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.                 -17-
  1061.  
  1062.  
  1063. or just a single side is operated on (existing applications
  1064. will have to be re-written to explicitly use the left and
  1065. right buffer ID's in order to successfully create, fetch,
  1066. and store stereo images).
  1067.  
  1068. Having an explicit CreateStereoWindow request is helpful in
  1069. that a server implementation will know from the onset
  1070. whether a stereo window is desired and can return appropri-
  1071. ate status to the client if it cannot support this function-
  1072. ality.
  1073.  
  1074. Some hardware may support separate stereo and non-stereo
  1075. modes, perhaps with different vertical resolutions.  For
  1076. example, the vertical resolution in stereo mode may be half
  1077. that of non-stereo mode.  Selecting one mode or the other
  1078. must be done through some means outside of this extension
  1079. (eg: by providing a separate screen for each hardware dis-
  1080. play mode).  The screen attributes (ie: x/y resolution) for
  1081. a screen that supports normal windows, may differ from a
  1082. screen that supports stereo windows; however, all windows,
  1083. regardless of type, displayed on the same screen must have
  1084. the same screen attributes (ie: pixel aspect ratio).
  1085.  
  1086. If a screen that supports stereo windows also supports nor-
  1087. mal windows, then the images presented to the left and right
  1088. eyes for normal windows should be the same (ie: have no
  1089. stereo offset).
  1090.  
  1091. Single-Buffered Stereo Windows
  1092.  
  1093. The following shows how to create and display a single-
  1094. buffered stereo image:
  1095.  
  1096.      /*
  1097.       * Create the stereo window, map it the screen,
  1098.       * and draw the left and right images
  1099.       */
  1100.      CreateStereoWindow( W, L, R, ... )
  1101.  
  1102.      MapWindow( W )
  1103.  
  1104.      <draw picture using L,R>
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126.                 -18-
  1127.  
  1128.  
  1129. Double-Buffering Stereo Windows
  1130.  
  1131. Additional image buffers may be added to a stereo window to
  1132. allow double or multi-buffering of stereo images.  Simply
  1133. use the the CreateImageBuffers request.  Even numbered
  1134. buffers (0,2,...) will be left buffers.  Odd numbered
  1135. buffers (1,3,...) will be right buffers.  Displayable stereo
  1136. images are formed by consecutive left/right pairs of image
  1137. buffers.  For example, (buffer[0],buffer[1]) form the first
  1138. displayable stereo image; (buffer[2],buffer[3]) the next;
  1139. and so on.
  1140.  
  1141. The CreateImageBuffers request will only create pairs of
  1142. left and right image buffers for stereo windows.  By always
  1143. pairing left and right image buffers together, implementa-
  1144. tions might be able to perform some type of optimization.
  1145. If an odd number of buffers is specified, a Value error is
  1146. generated.  All the rules mentioned at the start of this
  1147. proposal still apply to the image buffers supported by a
  1148. stereo window.
  1149.  
  1150. To display a image buffer pair of a multi-buffered stereo
  1151. image, either the left buffer ID or right buffer ID may be
  1152. specified in a DisplayImageBuffers request, but not both.
  1153.  
  1154. To double-buffer a stereo window:
  1155.  
  1156.  
  1157.  
  1158.  
  1159.  
  1160.  
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178.  
  1179.  
  1180.  
  1181.  
  1182.  
  1183.  
  1184.  
  1185.  
  1186.  
  1187.  
  1188.  
  1189.  
  1190.  
  1191.  
  1192.                 -19-
  1193.  
  1194.  
  1195.      /*
  1196.       * Create stereo window and map it to the screen
  1197.       */
  1198.      CreateStereoWindow( W, L, R, ... )
  1199.  
  1200.      /*
  1201.       * Create two pairs of image buffers.  Assume after display,
  1202.       * buffer contents become "undefined".  Assume we will "frequently"
  1203.       * update the display.  Abort if we did get all the buffers.
  1204.       */
  1205.      n = CreateImageBuffers( W, [L0,R0,L1,R1], Undefined, Frequently )
  1206.      if (n != 4) <abort>
  1207.  
  1208.      /*
  1209.       * Map window to the screen
  1210.       */
  1211.      MapWindow( W )
  1212.  
  1213.      /*
  1214.       * Draw images using alternate buffers,
  1215.       * display every 1/10 of a second.
  1216.       */
  1217.      while animating
  1218.      {
  1219.       <draw picture using L1,R1>
  1220.       DisplayImageBuffers( [L1], 100, 0 )
  1221.  
  1222.       <draw picture using L0,R0>
  1223.       DisplayImageBuffers( [L0], 100, 0 )
  1224.      }
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234.  
  1235.  
  1236.  
  1237.  
  1238.  
  1239.  
  1240.  
  1241.  
  1242.  
  1243.  
  1244.  
  1245.  
  1246.  
  1247.  
  1248.  
  1249.  
  1250.  
  1251.  
  1252.  
  1253.  
  1254.  
  1255.  
  1256.  
  1257.  
  1258.                 -20-
  1259.  
  1260.  
  1261. Multi-Buffering Stereo Windows
  1262.  
  1263. To cycle through N stereo images:
  1264.  
  1265.      /*
  1266.       * Create stereo window
  1267.       */
  1268.      CreateStereoWindow( W, L, R, ... )
  1269.  
  1270.      /*
  1271.       * Create N pairs of image buffers.  Assume after display,
  1272.       * buffer contents are "untouched".  Assume we will "frequently"
  1273.       * update the display.  Abort if we don't get all the buffers.
  1274.       */
  1275.      n = CreateImageBuffers( W, [L0,R0,...,L(N-1),R(N-1)], Untouched, Frequently )
  1276.      if (n != N*2) <abort>
  1277.  
  1278.      /*
  1279.       * Map window to screen
  1280.       */
  1281.      MapWindow( W )
  1282.  
  1283.      /*
  1284.       * Draw the left and right halves of each image
  1285.       */
  1286.      foreach stereo image
  1287.       <draw picture using L(i),R(i)>
  1288.  
  1289.      /*
  1290.       * Cycle through images every 1/10 of a second
  1291.       */
  1292.      while animating
  1293.      {
  1294.       foreach stereo image
  1295.            DisplayImageBuffers( [L(i)], 100, 0 )
  1296.      }
  1297.  
  1298.  
  1299.  
  1300.  
  1301.  
  1302.  
  1303.  
  1304.  
  1305.  
  1306.  
  1307.  
  1308.  
  1309.  
  1310.  
  1311.  
  1312.  
  1313.  
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323.  
  1324.                 -21-
  1325.  
  1326.  
  1327. Protocol Encoding
  1328.  
  1329. The official name of this extension is "Multi-Buffering".
  1330. When this string passed to QueryExtension the information
  1331. returned should be interpreted as follows:
  1332.  
  1333. major-opcode   Specifies the major opcode of this extension.
  1334.            The first byte of each extension request
  1335.            should specify this value.
  1336.  
  1337. first-event    Specifies the code that will be returned when
  1338.            ClobberNotify events are generated.
  1339.  
  1340. first-error    Specifies the code that will be returned when
  1341.            Buffer errors are generated.
  1342.  
  1343. The following sections describe the protocol encoding for
  1344. this extension.
  1345.  
  1346. TYPES
  1347.  
  1348. BUFFER_INFO
  1349.  
  1350. 4    VISUALID      visual
  1351. 2    CARD16          max-buffers
  1352. 1    CARD8          depth
  1353. 1              unused
  1354.  
  1355.  
  1356. SETofBUFFER_EVENT
  1357.  
  1358.     #x00008000      Exposure
  1359.     #x02000000      ClobberNotify
  1360.     #x04000000      UpdateNotify
  1361.  
  1362.  
  1363. EVENTS
  1364.  
  1365. ClobberNotify
  1366.  
  1367. 1    see first-event        code
  1368. 1                   unused
  1369. 2    CARD16               sequence number
  1370. 4    BUFFER               buffer
  1371. 1                   state
  1372.     0 Unclobbered
  1373.     1 PartiallyClobbered
  1374.     2 FullyClobbered
  1375. 23                   unused
  1376.  
  1377.  
  1378. UpdateNotify
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.                 -22-
  1391.  
  1392.  
  1393. 1    first-event+1      code
  1394. 1              unused
  1395. 2    CARD16          sequence number
  1396. 4    BUFFER          buffer
  1397. 24              unused
  1398.  
  1399.  
  1400. ERRORS
  1401.  
  1402. Buffer
  1403.  
  1404. 1    0          Error
  1405. 1    see first-error   code
  1406. 2    CARD16          sequence number
  1407. 4    CARD32          bad resource id
  1408. 2    CARD16          minor-opcode
  1409. 1    CARD8          major-opcode
  1410. 21              unused
  1411.  
  1412.  
  1413.  
  1414.  
  1415.  
  1416.  
  1417.  
  1418.  
  1419.  
  1420.  
  1421.  
  1422.  
  1423.  
  1424.  
  1425.  
  1426.  
  1427.  
  1428.  
  1429.  
  1430.  
  1431.  
  1432.  
  1433.  
  1434.  
  1435.  
  1436.  
  1437.  
  1438.  
  1439.  
  1440.  
  1441.  
  1442.  
  1443.  
  1444.  
  1445.  
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.                 -23-
  1457.  
  1458.  
  1459. REQUESTS
  1460.  
  1461. GetBufferVersion
  1462.  
  1463. 1    see major-opcode   major-opcode
  1464. 1    0           minor-opcode
  1465. 2    1           request length
  1466. ->
  1467. 1    1           Reply
  1468. 1               unused
  1469. 2    CARD16           sequence number
  1470. 4    0           reply length
  1471. 1    CARD8           major version number
  1472. 1    CARD8           minor version number
  1473. 22               unused
  1474.  
  1475.  
  1476. CreateImageBuffers
  1477.  
  1478. 1    see major-opcode   major-opcode
  1479. 1    1           minor-opcode
  1480. 2    3+n           request length
  1481. 4    WINDOW           wid
  1482. 1               update-action
  1483.     0 Undefined
  1484.     1 Background
  1485.     2 Untouched
  1486.     3 Copied
  1487. 1               update-hint
  1488.     0 Frequent
  1489.     1 Intermittent
  1490.     2 Static
  1491. 2               unused
  1492. 4n    LISTofBUFFER       buffer-list
  1493. ->
  1494. 1    1           Reply
  1495. 1               unused
  1496. 2    CARD16           sequence number
  1497. 4    0           reply length
  1498. 2    CARD16           number-buffers
  1499. 22               unused
  1500.  
  1501.  
  1502. DestroyImageBuffers
  1503.  
  1504. 1    see major-opcode   major-opcode
  1505. 1    2           minor-opcode
  1506. 2    2           request length
  1507. 4    WINDOW           wid
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514.  
  1515.  
  1516.  
  1517.  
  1518.  
  1519.  
  1520.  
  1521.  
  1522.                 -24-
  1523.  
  1524.  
  1525. DisplayImageBuffers
  1526.  
  1527. 1    see major-opcode   major-opcode
  1528. 1    3           minor-opcode
  1529. 2    2+n           request length
  1530. 2    CARD16           min-delay
  1531. 2    CARD16           max-delay
  1532. 4n    LISTofBUFFER       buffer-list
  1533.  
  1534.  
  1535. SetMultiBufferAttributes
  1536.  
  1537. 1     see major-opcode      major-opcode
  1538. 1     4              minor-opcode
  1539. 2     3+n              request length
  1540. 4     WINDOW           wid
  1541.  
  1542. 4     BITMASK          value-mask (has n bits set to 1)
  1543.      #x00000001 update-hint
  1544.  
  1545. 4n     LISTofVALUE          value-list
  1546.  
  1547. VALUEs
  1548. 1                  update-hint
  1549.      0 Frequent
  1550.      1 Intermittent
  1551.      2 Static
  1552.  
  1553.  
  1554.  
  1555.  
  1556.  
  1557.  
  1558.  
  1559.  
  1560.  
  1561.  
  1562.  
  1563.  
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570.  
  1571.  
  1572.  
  1573.  
  1574.  
  1575.  
  1576.  
  1577.  
  1578.  
  1579.  
  1580.  
  1581.  
  1582.  
  1583.  
  1584.  
  1585.  
  1586.  
  1587.  
  1588.                 -25-
  1589.  
  1590.  
  1591. GetMultiBufferAttributes
  1592.  
  1593. 1    see major-opcode   major-opcode
  1594. 1    5           minor-opcode
  1595. 2    2           request length
  1596. 4    WINDOW           wid
  1597. ->
  1598. 1    1           Reply
  1599. 1               unused
  1600. 2    CARD16           sequence number
  1601. 4    n           reply length
  1602. 2    CARD16           displayed-buffer
  1603. 1               update-action
  1604.     0 Undefined
  1605.     1 Background
  1606.     2 Untouched
  1607.     3 Copied
  1608. 1               update-hint
  1609.     0 Frequent
  1610.     1 Intermittent
  1611.     2 Static
  1612. 1               window-mode
  1613.     0 Mono
  1614.     1 Stereo
  1615. 19               unused
  1616. 4n    LISTofBUFFER       buffer list
  1617.  
  1618.  
  1619. SetBufferAttributes
  1620.  
  1621. 1     see major-opcode     major-opcode
  1622. 1     6             minor-opcode
  1623. 2     3+n             request length
  1624. 4     BUFFER          buffer
  1625.  
  1626. 4     BITMASK         value-mask (has n bits set to 1)
  1627.      #x00000001 event-mask
  1628.  
  1629. 4n     LISTofVALUE         value-list
  1630.  
  1631. VALUEs
  1632. 4     SETofBUFFER_EVENT     event-mask
  1633.  
  1634.  
  1635.  
  1636.  
  1637.  
  1638.  
  1639.  
  1640.  
  1641.  
  1642.  
  1643.  
  1644.  
  1645.  
  1646.  
  1647.  
  1648.  
  1649.  
  1650.  
  1651.  
  1652.  
  1653.  
  1654.                 -26-
  1655.  
  1656.  
  1657. GetBufferAttributes
  1658.  
  1659. 1    see major-opcode    major-opcode
  1660. 1    7            minor-opcode
  1661. 2    2            request length
  1662. 4    BUFFER            buffer
  1663. ->
  1664. 1    1            Reply
  1665. 1                unused
  1666. 2    CARD16            sequence number
  1667. 4    0            reply length
  1668. 4    WINDOW            wid
  1669. 4    SETofBUFFER_EVENT   event-mask
  1670. 2    CARD16            index
  1671. 1                side
  1672.     0 Mono
  1673.     1 Left
  1674.     2 Right
  1675. 13                unused
  1676.  
  1677.  
  1678. GetBufferInfo
  1679.  
  1680. 1    see major-opcode    major-opcode
  1681. 1    8            minor-opcode
  1682. 2    2            request length
  1683. 4    WINDOW            root
  1684. ->
  1685. 1    1            Reply
  1686. 1                unused
  1687. 2    CARD16            sequence number
  1688. 4    2(n+m)            reply length
  1689. 2    n            number BUFFER_INFO in normal-info
  1690. 2    m            number BUFFER_INFO in stereo-info
  1691. 20                unused
  1692. 8n    LISTofBUFFER_INFO   normal-info
  1693. 8m    LISTofBUFFER_INFO   stereo-info
  1694.  
  1695.  
  1696.  
  1697.  
  1698.  
  1699.  
  1700.  
  1701.  
  1702.  
  1703.  
  1704.  
  1705.  
  1706.  
  1707.  
  1708.  
  1709.  
  1710.  
  1711.  
  1712.  
  1713.  
  1714.  
  1715.  
  1716.  
  1717.  
  1718.  
  1719.  
  1720.                 -27-
  1721.  
  1722.  
  1723. CreateStereoWindow
  1724.  
  1725. 1    see major-opcode     major-opcode
  1726. 1    9             minor-opcode
  1727. 2    11+n             request length
  1728. 3                 unused
  1729. 1    CARD8             depth
  1730. 4    WINDOW             wid
  1731. 4    WINDOW             parent
  1732. 4    BUFFER             left
  1733. 4    BUFFER             right
  1734. 2    INT16             x
  1735. 2    INT16             y
  1736. 2    CARD16             width
  1737. 2    CARD16             height
  1738. 2    CARD16             border-width
  1739. 2                 class
  1740.     0 CopyFromParent
  1741.     1 InputOutput
  1742.     2 InputOnly
  1743.  
  1744. 4    VISUALID         visual
  1745.     0 CopyFromParent
  1746.  
  1747. 4    BITMASK          value-mask (has n bits set to 1)
  1748.     encodings are the same
  1749.     as for CreateWindow
  1750.  
  1751. 4n    LISTofVALUE         value-list
  1752.     encodings are the same
  1753.     as for CreateWindow
  1754.  
  1755.  
  1756. ClearImageBufferArea
  1757.  
  1758. 1    see major-opcode   major-opcode
  1759. 1    10           minor-opcode
  1760. 2    5           request length
  1761. 4    WINDOW           buffer
  1762. 2    INT16           x
  1763. 2    INT16           y
  1764. 2    CARD16           width
  1765. 2    CARD16           height
  1766. 3               unused
  1767. 1    BOOL           exposures
  1768.  
  1769.  
  1770.  
  1771.  
  1772.  
  1773.  
  1774.  
  1775.  
  1776.  
  1777.  
  1778.  
  1779.  
  1780.  
  1781.  
  1782.  
  1783.