Provided by: libggi-target-x_2.2.2-5ubuntu2_amd64 bug


       display-x - Displays to an X11 server


       display-x: [ [-inwin=<winid>|root] | [-screen=<screenidx>] ]
                  [-fullscreen] [-keepcursor] [-noaccel] [-nobuffer]
                  [-nocursor] [-nodbe] [-nodga] [-noevi] [-noinput]
                  [-nomansync] [-noshm] [-novidmode] [-physz=<sizex>,<sizey>[dpi]]


       display-x  displays  a  GGI  application  via  an  X11 server.  The server may be local or
       remote, and options are provided to tune performance  to  various  scenerios.   In  normal
       operation,  a  new X11 window is opened, solid fill primitives and copybox are accelerated
       by the server, and a backbuffer is  kept  client-side  for  content  fills  (e.g.  ggiPut*
       functions)  and to restore data when an application has been exposed after being concealed
       by another window.

       Ctrl-Alt-m toggles mouse grabbing in the new window.  It will try to  emulate  a  relative
       mouse  device,  i.e.  one  that can be moved arbitrarily far in any direction without ever
       leaving the window.  This is useful for game controls, where loosing  focus  is  generally
       undesireable.  Note that grabbing must be turned off in order to leave the window.


              The  X  display  to  connect  to,  otherwise  defaults  to the display specified in

              Turns on the fullscreen mode. Default mode is the  windowed  mode.   In  fullscreen
              mode,  the  dga  helper is tried first if not disabled by -nodga or failed for some
              reason. Then the vidmode helper is tried. When this fails, then  the  target  falls
              back to the windowed mode. Note, the -inwin option has no effect with fullscreen.

              All  rendering  is  performed  in  the client-side backbuffer, and then sent to the
              server; no  server-side  accelerated  graphics  operations  are  used.   This  will
              signifigantly  slow  down  certain graphics applications, but for applications that
              use  directbuffer  and  asyncronous  mode  extensively  the  effect  will  not   be
              noticeable.   The  only  real  reason  to use this option, however, is to eliminate
              artifacts caused by incorrectly implemented X11 hardware drivers.

              No client-side backbuffer is kept.  This may result in lost data  when  the  LibGGI
              application  is  obscured  by  other  windows.   This data loss can be minimized by
              enabling backing store in the X11 server.  Using this option will cause  operations
              which  must read back framebuffer data to be much slower, but on the other hand can
              result in a slight speed gain for certain graphics primitives.   It  is  best  used
              when  resources are severely limited on the client side, and with applications that
              do not perform frequent ggiPut* operations.  Note, with this option evExpose events
              are passed to the application (Otherwise, they are internally grabbed to update the

       -nodbe Use of the X11 DBE extension to provide buffered frame support is disabled.
              Note: Currently DBE extension support has not been completed.

       -nodga Use of the XFree86-DGA extension to provide direct framebuffer access is  disabled.
              Some  implementations  of  the XFree86-DGA extension may cause system lockups.  Use
              this option to prevent such occurrances.

       -noevi Use of the X11 Extended Visual Information extension to identify visuals which  are
              exclusively used for overlay/underlay is disabled.

              X events sent to the window are not captured and merged with any other LibGII input
              sources.  This allows  one  to  take  input  from  raw  devices  without  receiving
              duplicate events should X also be configured to use the device.

       -nocursor, -keepcursor
              Normal  behavior of display-x is to create a small dot mouse cursor pixmap which is
              visible when the mouse is positioned over the window containing the  visual.   This
              goes  away  when  using mouse grabbing as described above, but otherwise can get in
              the way of mouse cursors implemented by the application.  With the  former  option,
              the  X  mouse cursor will be invisible when it is over the visual, with the latter,
              the cursor from the root window is used unaltered.  If both options  are  supplied,
              the latter takes precedence.

              Use  of the mansync helper library to periodically flush backbuffer contents to the
              X11 server is disabled.  This, of course, will  result  in  incorrect  behavior  of
              applications that use syncronous mode.

       -noshm Use  of  the  MIT-SHM  extension to speed data transfer between clients and servers
              which are running on the same machine is disabled.  Normally it is not necessary to
              use  this  option,  as use of the MIT-SHM extension is disabled automatically if it
              appears to be nonfunctional.

              Run in already-existing window with id winid.  This can be used to embed  a  LibGGI
              application  into  an  X11  application.   The  value  should  be  an X11 window ID
              expressed as a "0x" prefixed hexadecimal number.  The special  string  "root"  will
              cause  the  application  to  run  in the root window of the selected screen (or the
              default screen if no explicit selection has been made.)   Note  that  in  the  root
              window, you may need to explicitly select a LibGII input source using the GGI_INPUT
              environment variable as the window manager will absorb all events sent to the  root
              window.   Some  features  (currently frames and virtual areas) may not work in root
              windows.  On the other hand, when using the root window other features like  direct
              framebuffer access and video hardware mode selection may be available which are not
              available when the application is running in a normal window.

              Use of the X11 Vidmode extension to change video timing  in  full-screen  modes  is
              disabled.   Some implementations of the Vidmode extension may cause system lockups.
              Use this option to prevent such occurrances.

              This option will override the physical screen size reported by the X server,  which
              affects  applications  which wish to remain resolution independent.  sizex,:p:sizey
              are the x,y size of the entire screen (not just the X window containing the visual)
              in  millimeters,  unless  the  optional  dpi string is affixed, in which case, they
              represent resolution in dots-per-inch. Yes, there are two equals signs  there,  for
              reasons of compatibility with other targets.

              The  screen  to  run  on.   Normally the biggest/deepest screen compatible with the
              requested mode will be chosen; with  this  option  only  the  screen  specified  by
              screenidx will be considered.


       The  old  X target rendered all primitives in a RAM backbuffer, and then copied the entire
       backbuffer periodically using the mansync helper to the X screen.  This caused  a  lot  of
       wasted  bandwidth.   However,  since  the  bandwidth  was  being wasted anyway, LibGGIMISC
       splitline support was a simple hack that added nearly no complexity.

       The old Xlib target had no RAM backbuffer and rendered all primitives  using  Xlib  calls.
       This  caused very slow performance when a lot of individual pixels were being drawn one at
       a time, and slow performance on operations which got pixel  data  back  from  the  visual,
       since  it  had  to  be  fetched  back  over the wire.  Also, this precluded the use of the
       directbuffer on the xlib target.

       The new X target in its default mode maintains both a RAM backbuffer on the  client  side,
       and uses Xlib primitives to draw on the server side.  When a primitive, such as a drawbox,
       can use an Xlib function, the command is dispatched to the X server and the  data  in  the
       RAM  buffer  is updated using a software renderer.  For operations such as putbox, the RAM
       buffer is updated first, and the synced to the X server.  Unlike the old target,  the  new
       target  keeps  track  of  a "dirty region" and only syncs the area affected since the last
       time a syncronization occured.   This  dirty-region  tracking  only  keeps  track  of  one
       rectangular  dirty  area.   A  helper  library that keeps track of more than one rectangle
       could be implemented to improve performance of display-X and any other similarly  designed
       display  target.   To  be  most  flexible  such  a  target should take weighted parameters
       representing the cost of transferring data (per byte) from the backbuffer,  and  the  per-
       operation  cost  of  initiating  such a transfer, which would alter its strategy as to how
       many regions are maintained and how much they overlap.

       The old X target's RAM buffer was implemented using the X target's drawops hooks  --  that
       is,  the  RAM  buffer was essentially a re-implementation of display-memory with the extra
       facilities to sync to the  X  server  built  in.   The  new  target  capitalizes  on  some
       improvements made in display-memory, and instead it opens and loads a child display-memory
       visual which takes care of finding software  renderers  for  the  RAM  buffer.   The  main
       drawops  of  the  new  target  dispatch  the  the  X  server commands and call the child's
       corresponsing software drawops to ensure consistant state of  the  RAM  buffer  vs  the  X
       window.   This must be done such that any requests to get data from the RAM backbuffer are
       not processed until the RAM backbuffer is up to date, and any flushes from the  backbuffer
       are  not processed until the backbuffer is up to date.  There's a lot of locking intracacy
       to ensure this level of consistancy.

       The basic syncronization operation is accomplished by the flush  function,  which  is  the
       function loaded on the xpriv flush member hook.  The flush hook function is called:

       1   When the mansync helper decides it is time to refresh the screen.

       2   After a primitive, if the visual is in syncronous rendering mode.

       3   When an expose or graphicsexpose event is sent from the server.  This means the server
           has discarded data that was concealed by another window or by the edge of the  screen,
           and the data must be resent from the client.

       In  the  last  case the whole area that must be refreshed is sent again by the client.  In
       the first two cases only the dirty area is sent, except when the  application  is  holding
       the  directbuffer  writing  resource,  in which case the whole area must be synced because
       there is no way for  the  target  to  tell  what  the  user  has  modified.   Holding  the
       directbuffer  write  resource  open  when  the  display is in syncronous mode or when also
       sending primitives will result in bad perfomance.  There's no  reason  to  do  so  on  any
       target, so don't.

       Unfortunately some XFree86 drivers are buggy, and when you render an accelerated primitive
       which overlaps an area which is not visible to the user, the driver fails  to  update  the
       backing  store  (it  only draws the clipped primitive using accelarated functions and does
       not complete the job by calling the software renderer to update the backing store.)   Most
       people will not be affected by this bug, however.

       The new X target implements gammamap (DirectColor), unlike the old targets.

       The  new  X  target is best used with backing store turned on in the server.  When backing
       store is not turned on, primitives which are clipped to the visual area but still  in  the
       virtual  area  may  be  slower  then the old target, since data will be sent to the server
       hoping it will be stored in the backing store.  Likewise when a full-screen flush  occurrs
       the entire virtual area data is sent.  The target could be optimized not to send this data
       when it detects that there is no backing store available in the server.

       Either the RAM backbuffer or the X primitives can be disabled via  target  options,  which
       will  cause  emulation of the old X (-noaccel) and Xlib (-nobuffer) targets, with a couple
       of notable exceptions:
              The old X and Xlib targets opened a window and drew directly into it.  The old Xlib
              target did not implement support for ggiSetOrigin.  As noted above the old X target
              used a hack that didn't cost  much  when  compared  to  the  cost  of  syncing  the
              backbuffer  periodically.   The  new  target  implements ggiSetOrigin by creating a
              parent window, then creating a child window inside the  parent  window.   Thus  the
              child  window  can  be moved around inside the parent window, and the parent window
              will clip the displayed data to the right size.  This is much more  efficient  than
              the old way when the server is keeping a backing store (which it sometimes does "in
              secret" even when the backing store functionality in the server is turned off.)
       Unfortunately many window managers seem to be buggy, and do not install the colormap of  a
       child  window  when  a mouse enters it.  This causes palette and gammamap to be messed up.
       Since so many windowmanagers  fail  to  implement  the  behavior  described  in  the  Xlib
       manpages, a workaround needs to be added which will not use the child window (this part is
       easy enough since the -inwin=root option already implements a  child-less  rendering)  and
       either  disables  ggiSetOrigin  support,  or  uses  a  better version of the old display-x
       target's creative blitting to emulate setorigin support.

       LibGGIMISC's splitline support for the original X display was broken  by  the  new  child-
       window  stuff as well.  In order to implement splitline support, libggimisc must implement
       a new set of primitives for the new display X that uses two child windows to  produce  the
       splitline  effect.  This complicates a lot of the primitives, so the code is best isolated
       in LibGGIMISC so any bugs or performance issues in it do not affect vanilla  LibGGI  users
       who  have  no need for splitline.  It would probably be best if the special renderers were
       only loaded on the first call to  ggiSetSplitline,  so  that  when  LibGGIMISC  implements
       support  for  the  XSync  extension,  users  who  are  not  using  splitline  do not pay a
       performance penalty for using XSync.

       The child window may also be to blame for the fact that a window which is focused, but not
       moused  over,  stops receiving keyboard events.  Reworking the X input target to take it's
       keyboard  events  from  the  parent  window  instead  of  the  child  window  (mouse   and
       expose/graphicsexpose  events  must  still come from the child window) would be the needed

       The new target tries to remove dl dependencies by creating a separate module file for  any
       X  extensions  used.  Because of some deficiencies in the X module system (there is no way
       to cleanly unload a module) some kludges have had to be made when a module is  loaded  but
       gleaned to be nonpresent, then unloaded.  This won't effect most people.

       However,  a  more  common  problem  will  be  seen  because  X does not give us any way to
       determine if the XSHM extension will work -- it tells us whether the server has XSHM,  but
       it  does  not tell us whether the client and server can share memory segments.  Thus, when
       running a remote client, it may be necessary to manually disable  XSHM  support  with  the
       -noshm target option.

       Anyway,  I hope this is helpful to any intrepid soul which decides to fondle this code :-)
       (Brian S. Julin)


       ·   DirectBuffer always available.

       ·   Accelerated

       ·   Multiple frames except for root window

       ·   Panning except for root window

       ·   Support Gammamap