Man Linux: Main Page and Category List


       ggiSetFlags,  ggiGetFlags,  ggiAddFlags,  ggiRemoveFlags  -  Set or get
       flags affecting operation on a visual


       #include <ggi/ggi.h>

       int ggiSetFlags(ggi_visual_t vis, ggi_flags flags);

       ggi_flags ggiGetFlags(ggi_visual_t vis);

       #define ggiAddFlags(vis,flags)  \
                     ggiSetFlags((vis), ggiGetFlags((vis)) | (flags))

       #define ggiRemoveFlags(vis,flags) \
                     ggiSetFlags((vis), ggiGetFlags((vis)) & ~(flags))


       ggiSetFlags sets the specified  flags  (bitwise  OR’d  together)  on  a

       ggiGetFlags obtains the flags currently in effect.

       ggiAddFlags  and  ggiRemoveFlags  are  macros  that  set  or  unset the
       specified flags.

       Flags are used to alter a  visual’s  underlying  behavior.   All  flags
       default  to  an  unset  value. Flags which are not supported by a given
       visual will remain unset even when an attempt is made  to  raise  them.
       Thus,  it  is possible to tell by reading back the flags whether or not
       each of the flags is supported by the given visual.
              Note: It is recommended to set the flags before setting a  mode,
              i.e. right after ggiOpen(3).


       ggiSetFlags,  ggiAddFlags,  and  ggiRemoveFlags  return 0 on success, a
       ggi-error(3) code on failure.  This will only happen if the failure  of
       a  target  to  support the addition or removal of a flag will cause the
       target to behave in a way that the application is not expecting.  As of
       this  writing  there are no such cases.  On visuals where certain flags
       are unsupported but are inconsequential, these functions will return  a
       successful return code, but will not actually set or clear the flag.

       ggiGetFlags returns the current flags.  This can be used by the curious
       to check whether a flag is being silently ignored as per above.


       Some visuals allow different modes with regard to when  the  screen  is
       updated and the actual drawing takes place.

       ·   In synchronous mode when the drawing command returns, it is already
           or will be executed very shortly. So the  visible  effect  is  that
           everything  is  drawn  immediately.   (It  is not guaranteed in the
           strict sense that it  is  already  drawn  when  the  function  call
           returns, but almost.)  This is the default mode for all visuals.

       ·   The  asynchronous mode does not guarantee that drawing commands are
           executed immediately, but is faster on many targets.  If the visual
           does  not  support  asynchronous  mode, attempting to set it has no
           effect.  Code written for asynchronous visuals will always  perform
           correctly on synchronous visuals (but not vice-versa), so it is not
           necessary to adapt  a  program’s  behavior  if  this  flag  is  not

           To make sure that all pending graphics operations are actually done
           and the screen is updated, you need to call ggiFlush(3).  This call
           is not needed in synchronous mode.

              Important: On some targets such as the X target there is no real
              synchronous mode, so LibGGI fakes one  by  periodically  calling
              ggiFlush(3) in the background.  This process can take about half
              the execution time of a program.  So using synchronous mode  can
              really slow things down.

              However,  the  synchronous  mode  is  the default, because it is
              what most programmers expect.
       In either mode, all operations are guaranteed to be  performed  in  the
       order in which they are called. Reordering is not done.

       GGI  guarantees  that  the  effects  of drawing operations on the final
       state of the buffer are consistant with the order in  which  they  were
       invoked,  but  as  to what order the operations visibly appear during a
       flush, that is entirely up to the target.  You could draw a red  square
       with  the GPU (through the target), and then draw a green square inside
       it via software -- you will always end up with a red  square  inside  a
       green square, but the user may see the red square appear first.

       When  it  comes  to  directbuffer, though, that is the problem that the
       TIDYBUF flag is meant to fix. Or at least, the  TIDYBUF  flag  fixes  a
       problem  with the way GGI fixes the serialization problem.  The display
       is flushed entirely before the acquire completes, and then  the  db  is
       flushed entirely before the db is released, so that is serialized.  The
       TIDYBUF stuff lets you bypass this serialization for efficiency.

       So the recommendation for all  graphics  applications  is  to  set  the
       asynchronous mode.  It will be far more efficient on some platforms and
       will never be worse.

       Setting up asynchronous mode:

       ggiAddFlags(vis, GGIFLAG_ASYNC);      /* switches to asynchronous mode */
       ggiFlush(vis);                        /* updates the screen */
       ggiRemoveFlags(vis, GGIFLAG_ASYNC);   /* switches to synchronous mode */


       Some visuals allow applications to manage their own dirty regions  when
       using the directbuffer.

       ·   In  the default dirty-buffering mode, visuals which use backbuffers
           to render to a display system will refresh the entire  screen  when
           the  resource  lock is held and then released for the write frame’s
           directbuffer.  This happens in  both  async  and  sync  modes.   In
           syncronous  modes  this  full-screen  refresh  may  be performed at
           regular intervals.  This can be very inefficient, but it guarantees
           that naive applications will be rendered correctly even though they
           were not written with a backbuffered display in mind.

           These visuals may also perform dirty-region tracking, such that  if
           the  directbuffer  is used, altered data may never reach the screen
           until the lock is released, because the visual does not know that a
           certain  area  of  the  backbuffer contains new (dirty) data.  Even
           explicitly calling ggiFlushRegion(3) on the affected area  may  not
           cause the data to be sent to the screen.

       ·   In   tidy-buffering   mode,  which  is  set  by  raising  the  flag
           GGIFLAG_TIDYBUF, visuals do not synchronize the screen at all  when
           the  write  frame’s  directbuffer lock is held or upon its release.
           However, in this mode,  ggiFlushRegion(3)  will  always  cause  the
           requested region of the screen to be updated.

           Note  that  this  means that, as long as the lock is held, affected
           regions may also have to be flushed (and thus, should  be  flushed)
           after normal drawing primitives are called.

           Before releasing the lock, applications should be sure to flush all
           affected regions, because the visual  may  revert  to  its  default
           dirty-region management behavior after the lock is released.

           Do  note,  also,  that  in  multi-frame  displays ggiFlushRegion(3)
           affects only the current write frame, so even though it is possible
           to  use  a  directbuffer  to alter a different frame, you must call
           ggiSetWriteFrame(3) to tell the visual that you  will  be  altering
           the frame.

       The  GGIFLAG_TIDYBUF  flag  is  not available on all visuals, but it is
       safe to attempt to set it whether or not it is available.  Code written
       for  the tidy-buffering mode will display correctly on visuals which do
       not have a tidy-buffering mode (but  not  vice-versa),  so  it  is  not
       necessary to adapt program behavior to its non-presence.

       It  is  recommended  that, if an application must use directbuffer, the
       application should attempt to place the visual in  tidy-buffered  mode.
       Do  note,  though,  that many applications that use the directbuffer do
       not actually need to do so and  probably  should  not,  as  it  reduces


       ggiFlush(3), ggiFlushRegion(3)