Provided by: libx11-protocol-other-perl_31-1_all bug


       X11::Protocol::Ext::DOUBLE_BUFFER - window off-screen double buffering


        use X11::Protocol;
        $X = X11::Protocol->new;
          or print "DOUBLE-BUFFER extension not available";


       The DOUBLE-BUFFER extension lets a program draw into an off-screen "back buffer" on a
       window and when ready swap it to the user-visible "front".  A back buffer is a drawable
       with the same size, depth, visibility, etc as the window proper.

       Drawing off-screen then swapping to visible is good for smooth frame by frame animations
       or if some drawing is complex or poorly implemented and has clears or overwriting which
       would flash if done directly to the window.

       Off-screen drawing can also be implemented by a pixmap and copy into the window but the
       server might implement a back buffer more efficiently.  In particular the back buffer only
       needs to be visible portions of a window so memory is not used for overlapped areas.

       The server might support double buffering only on certain visuals.  "DbeGetVisualInfo()"
       lists those which are supported, or just try to create a back buffer for a window and
       watch for an error reply.

       See examples/ for a simple program drawing with double buffering.


       The following requests are made available with an "init_extension()" per "EXTENSIONS" in

           my $bool = $X->init_extension('DOUBLE-BUFFER');

       "($server_major, $server_minor) = $X->DbeGetVersion ($client_major, $client_minor)"
           Negotiate a protocol version with the server.  $client_major and $client_minor is what
           the client would like, the returned $server_major and $server_minor is what the server
           will do, which might be less than requested (but not higher).

           The code here supports 1.0 and automatically negotiates within "init_extension()" so
           direct use of "DbeGetVersion()" is not necessary.

       "$X->DbeAllocateBackBufferName ($window, $buffer, $action_hint)"
           Create $buffer (a new XID) as the back buffer on $window.  $buffer is a drawable and
           can be used with all usual drawing operations.

               my $buffer = $X->new_rsrc;
               $X->DbeAllocateBackBufferName ($window, $buffer, 'Copied');

           $action_hint is the most likely $action in later "DbeSwapBuffers()" requests (see
           below).  But this is just a hint and doesn't restrict what can be done.

           If $window is already double buffered then $buffer becomes another reference to that
           back buffer.

           If $window is destroyed ("DestroyWindow()") then $buffer continues to exist and should
           still be deallocated (below), but attempting to draw into it gives a "Resource" error

       "$X->DbeDellocateBackBufferName ($buffer)"
           Deallocate $buffer and release that XID.

           If multiple "DbeAllocateBackBufferName()" requests have been made on a window then all
           the other XIDs continue to refer to the window back buffer.  The underlying buffer
           remains until all buffer XIDs for it are deallocated.

       "$X->DbeSwapBuffers ($window1,$action1, $window2,$action2,...)"
           Swap the front and back buffers on each given $window (XIDs).  The back buffer becomes
           visible and what was the front becomes the back.

             $X->DbeSwapBuffers ($window1, 'Background',
                                 $window2, 'Untouched');

           Only the content is swapped, the XIDs are unchanged, so $window is still the visible
           window front and any $buffer XIDs to it are still the back.

           The contents of each back buffer after swapping are controlled by the corresponding
           $action for each window (string type "DbeSwapAction"),

                $action        new back buffer contents
               ---------       --------------------------
               "Undefined"     undefined contents
               "Background"    cleared to the window background
               "Untouched"     left at current content (previous visible)
               "Copied"        content of the old back buffer (unchanged)

           "Untouched" means the contents of the front buffer are swapped to the back buffer

           "Copied" is as if the back buffer content is copied to the front, making both now the

       "$X->DbeBeginIdiom ()"
       "$X->DbeEndIdiom ()"
           Hint to the server that a sequence of swap and/or drawing operations between Begin and
           End might be done as an atomic combination for higher performance.  If the server
           doesn't recognise the sequence then it runs it sequentially as normal.

           If a "DbeSwapBuffers()" is in the idiom then it should be the first request,
           immediately following the Begin.

               # swap then clear back buffer to a GC stipple
               # no guarantee any server would actually optimize this!
               $X->DbeSwapBuffers ($window, 'Undefined');
               $X->PolyFillRectangle ($buffer, $gc, [0,0,$width,$height]);

           There doesn't need to be a swap in an idiom.  For example a "CopyArea()" of some parts
           of the back buffer to the window might be in a Begin/End and might perhaps be
           optimized by the server.

               $X->CopyArea ($buffer, $window,  # from buffer to window
                             $gc, $x,$y,$width,$height, $dstx,$dsty);
               # more stuff ...

           The idea of idiom groupings is to have a flexible way to express combination
           operations, including things not yet imagined, rather than adding specific requests to
           the protocol.  In principle the server can always optimize consecutive requests but
           that depends on them arriving at the server together.  A "DbeBeginIdiom()" is like
           permission to the server to defer performing the requests and wait, if it wishes, to
           see if what follows can be combined.

       "@infos = $X->DbeGetVisualInfo ($drawable1, $drawable2, ...)"
       "@infos = $X->DbeGetVisualInfo ()"
           For each $drawable, return a list of the visual IDs on that screen which support

               my ($info_aref_drawable1, $info_aref_drawable2)
                 = $X->DbeGetVisualInfo ($drawable1, $drawable2);

           If no drawables are given then return information about each screen on the server.

               my @list_of_info_aref = $X->DbeGetVisualInfo ();

           Each returned value is an arrayref.  Each arrayref contains a list of visual ID and
           visual data pairs,

               # each $info_aref is
               [ $visual_id1, [ $depth, $perflevel ],
                 $visual_id2, [ $depth, $perflevel ],

           $depth is the visual's depth the same as in the server info

           $perflevel is an integer indicating how good the performance of double buffering is on
           this visual.  A higher value means higher performance, but the actual number has no
           meaning and in particular cannot be compared between different servers.

           If enquiring about a single drawable's screen then use a list context like the
           following.  The result in scalar context is unspecified as yet.

               my ($info_aref) = $X->DbeGetVisualInfo ($X->root);

           The visual+perf are pairs so they can be put into a hash to check support for double
           buffering on a given visual,

               my %hash = @$info_aref;   # pairs $visualid => [$d,$p]
               if ($hash{$my_visual_id}) {
                 print "double buffering is available on my_visual_id\n";

           If you've got a choice of equally suitable visuals for application display then the
           performance level might be compared to choose the best.

           "List::Pairwise" has some grep and map functions for pair lists like the $info_aref.

           See examples/ for a simple program printing this info.

       "$window = $X->DbeGetBackBufferAttributes ($buffer)"
           Return the window (an integer XID) which $buffer is for.  If its target window has
           been destroyed ("DestroyWindow()") then the return is "None".


       The following types are available for "$X->interp()" and "$X->num()", after

               "Undefined"    0
               "Background"   1
               "Untouched"    2
               "Copied"       3

       For example,

           my $num = $X->num("DbeSwapAction", "Background");
           # sets $num to 2


       In some XFree86 3.x servers there was a bug in "DbeGetVisualInfo()" where the reply length
       was miscalculated, being bytes instead of CARD32s, resulting in a length value bigger than
       the actual data sent.  The symptom is the client hangs waiting for data the length says
       should follow but which never does.

       This affects all client code, including the Xlib "XdbeGetVisualInfo()" as used for
       instance by the "xdpyinfo" program.

       Is there a good way to notice the problem?  Probably not beyond looking at the server name
       and version and either forbidding the request or doing something nasty to the way
       "handle_input()" reads as a workaround.


       X11::Protocol, X11::Protocol::Ext::Composite





       Copyright 2011, 2012, 2013, 2014, 2017 Kevin Ryde

       X11-Protocol-Other is free software; you can redistribute it and/or modify it under the
       terms of the GNU General Public License as published by the Free Software Foundation;
       either version 3, or (at your option) any later version.

       X11-Protocol-Other is distributed in the hope that it will be useful, but WITHOUT ANY
       WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
       PURPOSE.  See the GNU General Public License for more details.

       You should have received a copy of the GNU General Public License along with
       X11-Protocol-Other.  If not, see <>.