Set or get flags affecting operation on a visual

Name

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

Synopsis

#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))

Description

ggiSetFlags sets the specified flags (bitwise OR'd together) on a visual.

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.

Return Value

ggiSetFlags, ggiAddFlags, and ggiRemoveFlags return 0 on success, <0 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.

Synchronous and Asynchronous drawing modes

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 in 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 visa-versa), so it is not necessary to adapt a program's behavior if this flag is not available.

    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.

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 */

Tidy buffer 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. 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.

See Also