Commit 6bfdecef authored by Javier Jardón's avatar Javier Jardón

docs: Move documentation to inline comments: gdkvisual

parent 9a8fcfa6
......@@ -12,4 +12,5 @@ keys.sgml
pango_interaction.sgml
pixbufs.sgml
regions.sgml
visuals.sgml
windows.sgml
<!-- ##### SECTION Title ##### -->
Visuals
<!-- ##### SECTION Short_Description ##### -->
Low-level display hardware information
<!-- ##### SECTION Long_Description ##### -->
<para>
A #GdkVisual describes a particular video hardware display format. It includes
information about the number of bits used for each color, the way the bits are
translated into an RGB value for display, and the way the bits are stored in
memory. For example, a piece of display hardware might support 24-bit color,
16-bit color, or 8-bit color; meaning 24/16/8-bit pixel sizes. For a given
pixel size, pixels can be in different formats; for example the "red" element
of an RGB pixel may be in the top 8 bits of the pixel, or may be in the lower
4 bits.
</para>
<para>
There are several standard visuals. The visual returned
by gdk_screen_get_system_visual() is the system's default
visual.
</para>
<para>
A number of functions are provided for determining
the "best" available visual. For the purposes of
making this determination, higher bit depths are
considered better, and for visuals of the same
bit depth, %GDK_VISUAL_PSEUDO_COLOR is preferred at
8bpp, otherwise, the visual types are ranked in the
order of (highest to lowest) %GDK_VISUAL_DIRECT_COLOR,
%GDK_VISUAL_TRUE_COLOR, %GDK_VISUAL_PSEUDO_COLOR,
%GDK_VISUAL_STATIC_COLOR, %GDK_VISUAL_GRAYSCALE,
then %GDK_VISUAL_STATIC_GRAY.
</para>
<!-- ##### SECTION See_Also ##### -->
<para>
</para>
<!-- ##### SECTION Stability_Level ##### -->
<!-- ##### SECTION Image ##### -->
<!-- ##### STRUCT GdkVisual ##### -->
<para>
The <type>GdkVisual</type> structure contains information about
a particular visual.
</para>
<example id="rgbmask">
<title>Constructing a pixel value from components</title>
<programlisting>
guint
pixel_from_rgb (GdkVisual *visual,
guchar r, guchar b, guchar g)
{
return ((r &gt;&gt; (16 - visual-&gt;red_prec)) &lt;&lt; visual-&gt;red_shift) |
((g &gt;&gt; (16 - visual-&gt;green_prec)) &lt;&lt; visual-&gt;green_shift) |
((r &gt;&gt; (16 - visual-&gt;blue_prec)) &lt;&lt; visual-&gt;blue_shift);
}
</programlisting>
</example>
@parent_instance: inherited portion from #GObject
<!-- ##### ENUM GdkVisualType ##### -->
<para>
A set of values that describe the manner in which the
pixel values for a visual are converted into RGB
values for display.
</para>
@GDK_VISUAL_STATIC_GRAY: Each pixel value indexes a grayscale value directly.
@GDK_VISUAL_GRAYSCALE: Each pixel is an index into a color map that maps pixel
values into grayscale values. The color map can be changed by an application.
@GDK_VISUAL_STATIC_COLOR: Each pixel value is an index into a predefined,
unmodifiable color map that maps pixel values into RGB values.
@GDK_VISUAL_PSEUDO_COLOR: Each pixel is an index into a color map that maps
pixel values into rgb values. The color map can be changed by an application.
@GDK_VISUAL_TRUE_COLOR: Each pixel value directly contains red, green,
and blue components. The <structfield>red_mask</structfield>,
<structfield>green_mask</structfield>, and
<structfield>blue_mask</structfield> fields of the #GdkVisual
structure describe how the components are assembled into a pixel value.
@GDK_VISUAL_DIRECT_COLOR: Each pixel value contains red, green, and blue
components as for %GDK_VISUAL_TRUE_COLOR, but the components are mapped via a
color table into the final output table instead of being converted directly.
<!-- ##### ENUM GdkByteOrder ##### -->
<para>
A set of values describing the possible byte-orders
for storing pixel values in memory.
</para>
@GDK_LSB_FIRST: The values are stored with the least-significant byte
first. For instance, the 32-bit value 0xffeecc would be stored
in memory as 0xcc, 0xee, 0xff, 0x00.
@GDK_MSB_FIRST: The values are stored with the most-significant byte
first. For instance, the 32-bit value 0xffeecc would be stored
in memory as 0x00, 0xcc, 0xee, 0xff.
<!-- ##### FUNCTION gdk_query_depths ##### -->
<para>
</para>
@depths:
@count:
<!-- ##### FUNCTION gdk_query_visual_types ##### -->
<para>
</para>
@visual_types:
@count:
<!-- ##### FUNCTION gdk_list_visuals ##### -->
<para>
</para>
@void:
@Returns:
<!-- ##### FUNCTION gdk_visual_get_bits_per_rgb ##### -->
<para>
</para>
@visual:
@Returns:
<!-- ##### FUNCTION gdk_visual_get_blue_pixel_details ##### -->
<para>
</para>
@visual:
@mask:
@shift:
@precision:
<!-- ##### FUNCTION gdk_visual_get_byte_order ##### -->
<para>
</para>
@visual:
@Returns:
<!-- ##### FUNCTION gdk_visual_get_colormap_size ##### -->
<para>
</para>
@visual:
@Returns:
<!-- ##### FUNCTION gdk_visual_get_depth ##### -->
<para>
</para>
@visual:
@Returns:
<!-- ##### FUNCTION gdk_visual_get_green_pixel_details ##### -->
<para>
</para>
@visual:
@mask:
@shift:
@precision:
<!-- ##### FUNCTION gdk_visual_get_red_pixel_details ##### -->
<para>
</para>
@visual:
@mask:
@shift:
@precision:
<!-- ##### FUNCTION gdk_visual_get_visual_type ##### -->
<para>
</para>
@visual:
@Returns:
<!-- ##### FUNCTION gdk_visual_get_best_depth ##### -->
<para>
</para>
@void:
@Returns:
<!-- ##### FUNCTION gdk_visual_get_best_type ##### -->
<para>
</para>
@void:
@Returns:
<!-- ##### FUNCTION gdk_visual_get_system ##### -->
<para>
</para>
@void:
@Returns:
<!-- ##### FUNCTION gdk_visual_get_best ##### -->
<para>
</para>
@void:
@Returns:
<!-- ##### FUNCTION gdk_visual_get_best_with_depth ##### -->
<para>
</para>
@depth:
@Returns:
<!-- ##### FUNCTION gdk_visual_get_best_with_type ##### -->
<para>
</para>
@visual_type:
@Returns:
<!-- ##### FUNCTION gdk_visual_get_best_with_both ##### -->
<para>
</para>
@depth:
@visual_type:
@Returns:
<!-- ##### FUNCTION gdk_visual_get_screen ##### -->
<para>
</para>
@visual:
@Returns:
......@@ -111,6 +111,18 @@ typedef struct _GdkDrawable GdkWindow;
typedef struct _GdkDisplay GdkDisplay;
typedef struct _GdkScreen GdkScreen;
/**
* GdkByteOrder:
* @GDK_LSB_FIRST: The values are stored with the least-significant byte
* first. For instance, the 32-bit value 0xffeecc would be stored
* in memory as 0xcc, 0xee, 0xff, 0x00.
* @GDK_MSB_FIRST: The values are stored with the most-significant byte
* first. For instance, the 32-bit value 0xffeecc would be stored
* in memory as 0x00, 0xcc, 0xee, 0xff.
*
* A set of values describing the possible byte-orders
* for storing pixel values in memory.
*/
typedef enum
{
GDK_LSB_FIRST,
......
......@@ -28,6 +28,33 @@
#include "gdkscreen.h"
/**
* SECTION:visuals
* @Short_description: Low-level display hardware information
* @Title: Visuals
*
* A #GdkVisual describes a particular video hardware display format. It includes
* information about the number of bits used for each color, the way the bits are
* translated into an RGB value for display, and the way the bits are stored in
* memory. For example, a piece of display hardware might support 24-bit color,
* 16-bit color, or 8-bit color; meaning 24/16/8-bit pixel sizes. For a given
* pixel size, pixels can be in different formats; for example the "red" element
* of an RGB pixel may be in the top 8 bits of the pixel, or may be in the lower
* 4 bits.
*
* There are several standard visuals. The visual returned by
* gdk_screen_get_system_visual() is the system's default visual.
*
* A number of functions are provided for determining the "best" available visual.
* For the purposes of making this determination, higher bit depths are considered
* better, and for visuals of the same bit depth, %GDK_VISUAL_PSEUDO_COLOR is
* preferred at 8bpp, otherwise, the visual types are ranked in the order of
* (highest to lowest) %GDK_VISUAL_DIRECT_COLOR, %GDK_VISUAL_TRUE_COLOR,
* %GDK_VISUAL_PSEUDO_COLOR, %GDK_VISUAL_STATIC_COLOR, %GDK_VISUAL_GRAYSCALE,
* then %GDK_VISUAL_STATIC_GRAY.
*/
/**
* gdk_list_visuals:
*
......
......@@ -79,29 +79,44 @@ typedef enum
GDK_VISUAL_DIRECT_COLOR
} GdkVisualType;
/* The visual type.
* "type" is the type of visual this is (PseudoColor, TrueColor, etc).
* "depth" is the bit depth of this visual.
* "colormap_size" is the size of a colormap for this visual.
* "bits_per_rgb" is the number of significant bits per red, green and blue.
* The red, green and blue masks, shifts and precisions refer
* to value needed to calculate pixel values in TrueColor and DirectColor
* visuals. The "mask" is the significant bits within the pixel. The
* "shift" is the number of bits left we must shift a primary for it
* to be in position (according to the "mask"). "prec" refers to how
* much precision the pixel value contains for a particular primary.
/**
* GdkVisual:
*
* The #GdkVisual structure contains information about
* a particular visual.
*
* <example id="rgbmask">
* <title>Constructing a pixel value from components</title>
* <programlisting>
* guint
* pixel_from_rgb (GdkVisual *visual,
* guchar r, guchar b, guchar g)
* {
* return ((r >> (16 - visual->red_prec)) << visual->red_shift) |
* ((g >> (16 - visual->green_prec)) << visual->green_shift) |
* ((r >> (16 - visual->blue_prec)) << visual->blue_shift);
* }
* </programlisting>
* </example>
*/
struct _GdkVisual
{
/*< private >*/
GObject parent_instance;
/*< private >*/
GdkVisualType GSEAL (type);
gint GSEAL (depth);
GdkVisualType GSEAL (type); /* Type of visual this is (PseudoColor, TrueColor, etc) */
gint GSEAL (depth); /* Bit depth of this visual */
GdkByteOrder GSEAL (byte_order);
gint GSEAL (colormap_size);
gint GSEAL (bits_per_rgb);
gint GSEAL (colormap_size); /* Size of a colormap for this visual */
gint GSEAL (bits_per_rgb); /* Number of significant bits per red, green and blue. */
/* The red, green and blue masks, shifts and precisions refer
* to value needed to calculate pixel values in TrueColor and DirectColor
* visuals. The "mask" is the significant bits within the pixel. The
* "shift" is the number of bits left we must shift a primary for it
* to be in position (according to the "mask"). "prec" refers to how
* much precision the pixel value contains for a particular primary.
*/
guint32 GSEAL (red_mask);
gint GSEAL (red_shift);
gint GSEAL (red_prec);
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment