cogl: Put CoglPixelFormat code into its own file

We're going to add some features and extra code to CoglPixelFormat, so
it's much nicer to have it in once place. Notice also that it doesn't
make sense that e.g. `_cogl_pixel_format_get_bytes_per_pixel()` were in
a private header, since they were being exported anyway.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/524
This commit is contained in:
Niels De Graef 2019-04-04 11:02:47 +02:00
parent 358b67871f
commit 991f9505ad
10 changed files with 384 additions and 269 deletions

View File

@ -43,6 +43,7 @@ typedef struct _CoglBitmap CoglBitmap;
#include <cogl/cogl-buffer.h>
#include <cogl/cogl-context.h>
#include <cogl/cogl-pixel-buffer.h>
#include <cogl/cogl-pixel-format.h>
#include <glib-object.h>

View File

@ -0,0 +1,89 @@
/*
* Cogl
*
* A Low Level GPU Graphics and Utilities API
*
* Copyright (C) 2007,2008,2009,2010 Intel Corporation.
*
* Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
* files (the "Software"), to deal in the Software without
* restriction, including without limitation the rights to use, copy,
* modify, merge, publish, distribute, sublicense, and/or sell copies
* of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be
* included in all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*
*
*/
#include "cogl-config.h"
#include <string.h>
#include <math.h>
#include <stdlib.h>
#include "cogl-pixel-format.h"
/*
* Returns the number of bytes-per-pixel of a given format. The bpp
* can be extracted from the least significant nibble of the pixel
* format (see CoglPixelFormat).
*
* The mapping is the following (see discussion on bug #660188):
*
* 0 = undefined
* 1, 8 = 1 bpp (e.g. A_8, G_8)
* 2 = 3 bpp, aligned (e.g. 888)
* 3 = 4 bpp, aligned (e.g. 8888)
* 4-6 = 2 bpp, not aligned (e.g. 565, 4444, 5551)
* 7 = undefined yuv
* 9 = 2 bpp, aligned
* 10 = undefined
* 11 = undefined
* 12 = 3 bpp, not aligned
* 13 = 4 bpp, not aligned (e.g. 2101010)
* 14-15 = undefined
*/
int
_cogl_pixel_format_get_bytes_per_pixel (CoglPixelFormat format)
{
int bpp_lut[] = { 0, 1, 3, 4,
2, 2, 2, 0,
1, 2, 0, 0,
3, 4, 0, 0 };
return bpp_lut [format & 0xf];
}
/* Note: this also refers to the mapping defined above for
* _cogl_pixel_format_get_bytes_per_pixel() */
gboolean
_cogl_pixel_format_is_endian_dependant (CoglPixelFormat format)
{
int aligned_lut[] = { -1, 1, 1, 1,
0, 0, 0, -1,
1, 1, -1, -1,
0, 0, -1, -1};
int aligned = aligned_lut[format & 0xf];
g_return_val_if_fail (aligned != -1, FALSE);
/* NB: currently checking whether the format components are aligned
* or not determines whether the format is endian dependent or not.
* In the future though we might consider adding formats with
* aligned components that are also endian independant. */
return aligned;
}

View File

@ -0,0 +1,289 @@
/*
* Cogl
*
* A Low Level GPU Graphics and Utilities API
*
* Copyright (C) 2008,2009 Intel Corporation.
*
* Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
* files (the "Software"), to deal in the Software without
* restriction, including without limitation the rights to use, copy,
* modify, merge, publish, distribute, sublicense, and/or sell copies
* of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be
* included in all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*
*
*/
#if !defined(__COGL_H_INSIDE__) && !defined(COGL_COMPILATION)
#error "Only <cogl/cogl.h> can be included directly."
#endif
#ifndef __COGL_PIXEL_FORMAT_H__
#define __COGL_PIXEL_FORMAT_H__
#include <stdint.h>
#include <stddef.h>
#include <cogl/cogl-defines.h>
#include <glib.h>
#include <glib-object.h>
G_BEGIN_DECLS
/**
* SECTION:cogl-pixel-format
* @short_description: Pixel formats supported by Cogl
*
* The pixel format of an image descrbes how the bits of each pixel are
* represented in memory. For example: an image can be laid out as one long
* sequence of pixels, where each pixel is a sequence of 8 bits of Red, Green
* and Blue. The amount of bits that are used can be different for each pixel
* format, as well as the components (for example an Alpha layer to include
* transparency, or non_RGBA).
*
* Other examples of factors that can influence the layout in memory are the
* system's endianness.
*/
#define COGL_A_BIT (1 << 4)
#define COGL_BGR_BIT (1 << 5)
#define COGL_AFIRST_BIT (1 << 6)
#define COGL_PREMULT_BIT (1 << 7)
#define COGL_DEPTH_BIT (1 << 8)
#define COGL_STENCIL_BIT (1 << 9)
/* XXX: Notes to those adding new formats here...
*
* First this diagram outlines how we allocate the 32bits of a
* CoglPixelFormat currently...
*
* 6 bits for flags
* |-----|
* enum unused 4 bits for the bytes-per-pixel
* and component alignment info
* |------| |-------------| |--|
* 00000000 xxxxxxxx xxxxxxSD PFBA0000
* ^ stencil
* ^ depth
* ^ premult
* ^ alpha first
* ^ bgr order
* ^ has alpha
*
* The most awkward part about the formats is how we use the last 4
* bits to encode the bytes per pixel and component alignment
* information. Ideally we should have had 3 bits for the bpp and a
* flag for alignment but we didn't plan for that in advance so we
* instead use a small lookup table to query the bpp and whether the
* components are byte aligned or not.
*
* The mapping is the following (see discussion on bug #660188):
*
* 0 = undefined
* 1, 8 = 1 bpp (e.g. A_8, G_8)
* 2 = 3 bpp, aligned (e.g. 888)
* 3 = 4 bpp, aligned (e.g. 8888)
* 4-6 = 2 bpp, not aligned (e.g. 565, 4444, 5551)
* 7 = YUV: undefined bpp, undefined alignment
* 9 = 2 bpp, aligned
* 10 = depth, aligned (8, 16, 24, 32, 32f)
* 11 = undefined
* 12 = 3 bpp, not aligned
* 13 = 4 bpp, not aligned (e.g. 2101010)
* 14-15 = undefined
*
* Note: the gap at 10-11 is just because we wanted to maintain that
* all non-aligned formats have the third bit set in case that's
* useful later.
*
* Since we don't want to waste bits adding more and more flags, we'd
* like to see most new pixel formats that can't be represented
* uniquely with the existing flags in the least significant byte
* simply be enumerated with sequential values in the most significant
* enum byte.
*
* Note: Cogl avoids exposing any padded XRGB or RGBX formats and
* instead we leave it up to applications to decided whether they
* consider the A component as padding or valid data. We shouldn't
* change this policy without good reasoning.
*
* So to add a new format:
* 1) Use the mapping table above to figure out what to but in
* the lowest nibble.
* 2) OR in the COGL_PREMULT_BIT, COGL_AFIRST_BIT, COGL_A_BIT and
* COGL_BGR_BIT flags as appropriate.
* 3) If the result is not yet unique then also combine with an
* increment of the last sequence number in the most significant
* byte.
*
* The last sequence number used was 0 (i.e. no formats currently need
* a sequence number)
* Update this note whenever a new sequence number is used.
*/
/**
* CoglPixelFormat:
* @COGL_PIXEL_FORMAT_ANY: Any format
* @COGL_PIXEL_FORMAT_A_8: 8 bits alpha mask
* @COGL_PIXEL_FORMAT_RG_88: RG, 16 bits. Note that red-green textures
* are only available if %COGL_FEATURE_ID_TEXTURE_RG is advertised.
* See cogl_texture_set_components() for details.
* @COGL_PIXEL_FORMAT_RGB_565: RGB, 16 bits
* @COGL_PIXEL_FORMAT_RGBA_4444: RGBA, 16 bits
* @COGL_PIXEL_FORMAT_RGBA_5551: RGBA, 16 bits
* @COGL_PIXEL_FORMAT_YUV: Not currently supported
* @COGL_PIXEL_FORMAT_G_8: Single luminance component
* @COGL_PIXEL_FORMAT_RGB_888: RGB, 24 bits
* @COGL_PIXEL_FORMAT_BGR_888: BGR, 24 bits
* @COGL_PIXEL_FORMAT_RGBA_8888: RGBA, 32 bits
* @COGL_PIXEL_FORMAT_BGRA_8888: BGRA, 32 bits
* @COGL_PIXEL_FORMAT_ARGB_8888: ARGB, 32 bits
* @COGL_PIXEL_FORMAT_ABGR_8888: ABGR, 32 bits
* @COGL_PIXEL_FORMAT_RGBA_1010102 : RGBA, 32 bits, 10 bpc
* @COGL_PIXEL_FORMAT_BGRA_1010102 : BGRA, 32 bits, 10 bpc
* @COGL_PIXEL_FORMAT_ARGB_2101010 : ARGB, 32 bits, 10 bpc
* @COGL_PIXEL_FORMAT_ABGR_2101010 : ABGR, 32 bits, 10 bpc
* @COGL_PIXEL_FORMAT_RGBA_8888_PRE: Premultiplied RGBA, 32 bits
* @COGL_PIXEL_FORMAT_BGRA_8888_PRE: Premultiplied BGRA, 32 bits
* @COGL_PIXEL_FORMAT_ARGB_8888_PRE: Premultiplied ARGB, 32 bits
* @COGL_PIXEL_FORMAT_ABGR_8888_PRE: Premultiplied ABGR, 32 bits
* @COGL_PIXEL_FORMAT_RGBA_4444_PRE: Premultiplied RGBA, 16 bits
* @COGL_PIXEL_FORMAT_RGBA_5551_PRE: Premultiplied RGBA, 16 bits
* @COGL_PIXEL_FORMAT_RGBA_1010102_PRE: Premultiplied RGBA, 32 bits, 10 bpc
* @COGL_PIXEL_FORMAT_BGRA_1010102_PRE: Premultiplied BGRA, 32 bits, 10 bpc
* @COGL_PIXEL_FORMAT_ARGB_2101010_PRE: Premultiplied ARGB, 32 bits, 10 bpc
* @COGL_PIXEL_FORMAT_ABGR_2101010_PRE: Premultiplied ABGR, 32 bits, 10 bpc
*
* Pixel formats used by Cogl. For the formats with a byte per
* component, the order of the components specify the order in
* increasing memory addresses. So for example
* %COGL_PIXEL_FORMAT_RGB_888 would have the red component in the
* lowest address, green in the next address and blue after that
* regardless of the endianness of the system.
*
* For the formats with non byte aligned components the component
* order specifies the order within a 16-bit or 32-bit number from
* most significant bit to least significant. So for
* %COGL_PIXEL_FORMAT_RGB_565, the red component would be in bits
* 11-15, the green component would be in 6-11 and the blue component
* would be in 1-5. Therefore the order in memory depends on the
* endianness of the system.
*
* When uploading a texture %COGL_PIXEL_FORMAT_ANY can be used as the
* internal format. Cogl will try to pick the best format to use
* internally and convert the texture data if necessary.
*
* Since: 0.8
*/
typedef enum /*< prefix=COGL_PIXEL_FORMAT >*/
{
COGL_PIXEL_FORMAT_ANY = 0,
COGL_PIXEL_FORMAT_A_8 = 1 | COGL_A_BIT,
COGL_PIXEL_FORMAT_RGB_565 = 4,
COGL_PIXEL_FORMAT_RGBA_4444 = 5 | COGL_A_BIT,
COGL_PIXEL_FORMAT_RGBA_5551 = 6 | COGL_A_BIT,
COGL_PIXEL_FORMAT_YUV = 7,
COGL_PIXEL_FORMAT_G_8 = 8,
COGL_PIXEL_FORMAT_RG_88 = 9,
COGL_PIXEL_FORMAT_RGB_888 = 2,
COGL_PIXEL_FORMAT_BGR_888 = (2 | COGL_BGR_BIT),
COGL_PIXEL_FORMAT_RGBA_8888 = (3 | COGL_A_BIT),
COGL_PIXEL_FORMAT_BGRA_8888 = (3 | COGL_A_BIT | COGL_BGR_BIT),
COGL_PIXEL_FORMAT_ARGB_8888 = (3 | COGL_A_BIT | COGL_AFIRST_BIT),
COGL_PIXEL_FORMAT_ABGR_8888 = (3 | COGL_A_BIT | COGL_BGR_BIT | COGL_AFIRST_BIT),
COGL_PIXEL_FORMAT_RGBA_1010102 = (13 | COGL_A_BIT),
COGL_PIXEL_FORMAT_BGRA_1010102 = (13 | COGL_A_BIT | COGL_BGR_BIT),
COGL_PIXEL_FORMAT_ARGB_2101010 = (13 | COGL_A_BIT | COGL_AFIRST_BIT),
COGL_PIXEL_FORMAT_ABGR_2101010 = (13 | COGL_A_BIT | COGL_BGR_BIT | COGL_AFIRST_BIT),
COGL_PIXEL_FORMAT_RGBA_8888_PRE = (3 | COGL_A_BIT | COGL_PREMULT_BIT),
COGL_PIXEL_FORMAT_BGRA_8888_PRE = (3 | COGL_A_BIT | COGL_PREMULT_BIT | COGL_BGR_BIT),
COGL_PIXEL_FORMAT_ARGB_8888_PRE = (3 | COGL_A_BIT | COGL_PREMULT_BIT | COGL_AFIRST_BIT),
COGL_PIXEL_FORMAT_ABGR_8888_PRE = (3 | COGL_A_BIT | COGL_PREMULT_BIT | COGL_BGR_BIT | COGL_AFIRST_BIT),
COGL_PIXEL_FORMAT_RGBA_4444_PRE = (COGL_PIXEL_FORMAT_RGBA_4444 | COGL_A_BIT | COGL_PREMULT_BIT),
COGL_PIXEL_FORMAT_RGBA_5551_PRE = (COGL_PIXEL_FORMAT_RGBA_5551 | COGL_A_BIT | COGL_PREMULT_BIT),
COGL_PIXEL_FORMAT_RGBA_1010102_PRE = (COGL_PIXEL_FORMAT_RGBA_1010102 | COGL_PREMULT_BIT),
COGL_PIXEL_FORMAT_BGRA_1010102_PRE = (COGL_PIXEL_FORMAT_BGRA_1010102 | COGL_PREMULT_BIT),
COGL_PIXEL_FORMAT_ARGB_2101010_PRE = (COGL_PIXEL_FORMAT_ARGB_2101010 | COGL_PREMULT_BIT),
COGL_PIXEL_FORMAT_ABGR_2101010_PRE = (COGL_PIXEL_FORMAT_ABGR_2101010 | COGL_PREMULT_BIT),
COGL_PIXEL_FORMAT_DEPTH_16 = (9 | COGL_DEPTH_BIT),
COGL_PIXEL_FORMAT_DEPTH_32 = (3 | COGL_DEPTH_BIT),
COGL_PIXEL_FORMAT_DEPTH_24_STENCIL_8 = (3 | COGL_DEPTH_BIT | COGL_STENCIL_BIT)
} CoglPixelFormat;
/*
* _cogl_pixel_format_get_bytes_per_pixel:
* @format: a #CoglPixelFormat
*
* Queries how many bytes a pixel of the given @format takes.
*
* Return value: The number of bytes taken for a pixel of the given
* @format.
*/
int
_cogl_pixel_format_get_bytes_per_pixel (CoglPixelFormat format);
/*
* _cogl_pixel_format_has_aligned_components:
* @format: a #CoglPixelFormat
*
* Queries whether the ordering of the components for the given
* @format depend on the endianness of the host CPU or if the
* components can be accessed using bit shifting and bitmasking by
* loading a whole pixel into a word.
*
* XXX: If we ever consider making something like this public we
* should really try to think of a better name and come up with
* much clearer documentation since it really depends on what
* point of view you consider this from whether a format like
* COGL_PIXEL_FORMAT_RGBA_8888 is endian dependent. E.g. If you
* read an RGBA_8888 pixel into a uint32
* it's endian dependent how you mask out the different channels.
* But If you already have separate color components and you want
* to write them to an RGBA_8888 pixel then the bytes can be
* written sequentially regardless of the endianness.
*
* Return value: %TRUE if you need to consider the host CPU
* endianness when dealing with the given @format
* else %FALSE.
*/
gboolean
_cogl_pixel_format_is_endian_dependant (CoglPixelFormat format);
/*
* COGL_PIXEL_FORMAT_CAN_HAVE_PREMULT(format):
* @format: a #CoglPixelFormat
*
* Returns TRUE if the pixel format can take a premult bit. This is
* currently true for all formats that have an alpha channel except
* COGL_PIXEL_FORMAT_A_8 (because that doesn't have any other
* components to multiply by the alpha).
*/
#define COGL_PIXEL_FORMAT_CAN_HAVE_PREMULT(format) \
(((format) & COGL_A_BIT) && (format) != COGL_PIXEL_FORMAT_A_8)
G_END_DECLS
#endif /* __COGL_PIXEL_FORMAT_H__ */

View File

@ -116,57 +116,6 @@ _cogl_get_enable_legacy_state (void);
#define _cogl_has_private_feature(ctx, feature) \
COGL_FLAGS_GET ((ctx)->private_features, (feature))
/*
* _cogl_pixel_format_get_bytes_per_pixel:
* @format: a #CoglPixelFormat
*
* Queries how many bytes a pixel of the given @format takes.
*
* Return value: The number of bytes taken for a pixel of the given
* @format.
*/
int
_cogl_pixel_format_get_bytes_per_pixel (CoglPixelFormat format);
/*
* _cogl_pixel_format_has_aligned_components:
* @format: a #CoglPixelFormat
*
* Queries whether the ordering of the components for the given
* @format depend on the endianness of the host CPU or if the
* components can be accessed using bit shifting and bitmasking by
* loading a whole pixel into a word.
*
* XXX: If we ever consider making something like this public we
* should really try to think of a better name and come up with
* much clearer documentation since it really depends on what
* point of view you consider this from whether a format like
* COGL_PIXEL_FORMAT_RGBA_8888 is endian dependent. E.g. If you
* read an RGBA_8888 pixel into a uint32
* it's endian dependent how you mask out the different channels.
* But If you already have separate color components and you want
* to write them to an RGBA_8888 pixel then the bytes can be
* written sequentially regardless of the endianness.
*
* Return value: %TRUE if you need to consider the host CPU
* endianness when dealing with the given @format
* else %FALSE.
*/
gboolean
_cogl_pixel_format_is_endian_dependant (CoglPixelFormat format);
/*
* COGL_PIXEL_FORMAT_CAN_HAVE_PREMULT(format):
* @format: a #CoglPixelFormat
*
* Returns TRUE if the pixel format can take a premult bit. This is
* currently true for all formats that have an alpha channel except
* COGL_PIXEL_FORMAT_A_8 (because that doesn't have any other
* components to multiply by the alpha).
*/
#define COGL_PIXEL_FORMAT_CAN_HAVE_PREMULT(format) \
(((format) & COGL_A_BIT) && (format) != COGL_PIXEL_FORMAT_A_8)
G_END_DECLS
#endif /* __COGL_PRIVATE_H__ */

View File

@ -53,6 +53,7 @@ typedef struct _CoglTexture CoglTexture;
#include <cogl/cogl-macros.h>
#include <cogl/cogl-defines.h>
#include <cogl/cogl-pixel-buffer.h>
#include <cogl/cogl-pixel-format.h>
#include <cogl/cogl-bitmap.h>
#include <glib-object.h>

View File

@ -147,172 +147,6 @@ typedef struct _CoglTextureVertex CoglTextureVertex;
#define COGL_DEPTH_BIT (1 << 8)
#define COGL_STENCIL_BIT (1 << 9)
/* XXX: Notes to those adding new formats here...
*
* First this diagram outlines how we allocate the 32bits of a
* CoglPixelFormat currently...
*
* 6 bits for flags
* |-----|
* enum unused 4 bits for the bytes-per-pixel
* and component alignment info
* |------| |-------------| |--|
* 00000000 xxxxxxxx xxxxxxSD PFBA0000
* ^ stencil
* ^ depth
* ^ premult
* ^ alpha first
* ^ bgr order
* ^ has alpha
*
* The most awkward part about the formats is how we use the last 4
* bits to encode the bytes per pixel and component alignment
* information. Ideally we should have had 3 bits for the bpp and a
* flag for alignment but we didn't plan for that in advance so we
* instead use a small lookup table to query the bpp and whether the
* components are byte aligned or not.
*
* The mapping is the following (see discussion on bug #660188):
*
* 0 = undefined
* 1, 8 = 1 bpp (e.g. A_8, G_8)
* 2 = 3 bpp, aligned (e.g. 888)
* 3 = 4 bpp, aligned (e.g. 8888)
* 4-6 = 2 bpp, not aligned (e.g. 565, 4444, 5551)
* 7 = YUV: undefined bpp, undefined alignment
* 9 = 2 bpp, aligned
* 10 = depth, aligned (8, 16, 24, 32, 32f)
* 11 = undefined
* 12 = 3 bpp, not aligned
* 13 = 4 bpp, not aligned (e.g. 2101010)
* 14-15 = undefined
*
* Note: the gap at 10-11 is just because we wanted to maintain that
* all non-aligned formats have the third bit set in case that's
* useful later.
*
* Since we don't want to waste bits adding more and more flags, we'd
* like to see most new pixel formats that can't be represented
* uniquely with the existing flags in the least significant byte
* simply be enumerated with sequential values in the most significant
* enum byte.
*
* Note: Cogl avoids exposing any padded XRGB or RGBX formats and
* instead we leave it up to applications to decided whether they
* consider the A component as padding or valid data. We shouldn't
* change this policy without good reasoning.
*
* So to add a new format:
* 1) Use the mapping table above to figure out what to but in
* the lowest nibble.
* 2) OR in the COGL_PREMULT_BIT, COGL_AFIRST_BIT, COGL_A_BIT and
* COGL_BGR_BIT flags as appropriate.
* 3) If the result is not yet unique then also combine with an
* increment of the last sequence number in the most significant
* byte.
*
* The last sequence number used was 0 (i.e. no formats currently need
* a sequence number)
* Update this note whenever a new sequence number is used.
*/
/**
* CoglPixelFormat:
* @COGL_PIXEL_FORMAT_ANY: Any format
* @COGL_PIXEL_FORMAT_A_8: 8 bits alpha mask
* @COGL_PIXEL_FORMAT_RG_88: RG, 16 bits. Note that red-green textures
* are only available if %COGL_FEATURE_ID_TEXTURE_RG is advertised.
* See cogl_texture_set_components() for details.
* @COGL_PIXEL_FORMAT_RGB_565: RGB, 16 bits
* @COGL_PIXEL_FORMAT_RGBA_4444: RGBA, 16 bits
* @COGL_PIXEL_FORMAT_RGBA_5551: RGBA, 16 bits
* @COGL_PIXEL_FORMAT_YUV: Not currently supported
* @COGL_PIXEL_FORMAT_G_8: Single luminance component
* @COGL_PIXEL_FORMAT_RGB_888: RGB, 24 bits
* @COGL_PIXEL_FORMAT_BGR_888: BGR, 24 bits
* @COGL_PIXEL_FORMAT_RGBA_8888: RGBA, 32 bits
* @COGL_PIXEL_FORMAT_BGRA_8888: BGRA, 32 bits
* @COGL_PIXEL_FORMAT_ARGB_8888: ARGB, 32 bits
* @COGL_PIXEL_FORMAT_ABGR_8888: ABGR, 32 bits
* @COGL_PIXEL_FORMAT_RGBA_1010102 : RGBA, 32 bits, 10 bpc
* @COGL_PIXEL_FORMAT_BGRA_1010102 : BGRA, 32 bits, 10 bpc
* @COGL_PIXEL_FORMAT_ARGB_2101010 : ARGB, 32 bits, 10 bpc
* @COGL_PIXEL_FORMAT_ABGR_2101010 : ABGR, 32 bits, 10 bpc
* @COGL_PIXEL_FORMAT_RGBA_8888_PRE: Premultiplied RGBA, 32 bits
* @COGL_PIXEL_FORMAT_BGRA_8888_PRE: Premultiplied BGRA, 32 bits
* @COGL_PIXEL_FORMAT_ARGB_8888_PRE: Premultiplied ARGB, 32 bits
* @COGL_PIXEL_FORMAT_ABGR_8888_PRE: Premultiplied ABGR, 32 bits
* @COGL_PIXEL_FORMAT_RGBA_4444_PRE: Premultiplied RGBA, 16 bits
* @COGL_PIXEL_FORMAT_RGBA_5551_PRE: Premultiplied RGBA, 16 bits
* @COGL_PIXEL_FORMAT_RGBA_1010102_PRE: Premultiplied RGBA, 32 bits, 10 bpc
* @COGL_PIXEL_FORMAT_BGRA_1010102_PRE: Premultiplied BGRA, 32 bits, 10 bpc
* @COGL_PIXEL_FORMAT_ARGB_2101010_PRE: Premultiplied ARGB, 32 bits, 10 bpc
* @COGL_PIXEL_FORMAT_ABGR_2101010_PRE: Premultiplied ABGR, 32 bits, 10 bpc
*
* Pixel formats used by Cogl. For the formats with a byte per
* component, the order of the components specify the order in
* increasing memory addresses. So for example
* %COGL_PIXEL_FORMAT_RGB_888 would have the red component in the
* lowest address, green in the next address and blue after that
* regardless of the endianness of the system.
*
* For the formats with non byte aligned components the component
* order specifies the order within a 16-bit or 32-bit number from
* most significant bit to least significant. So for
* %COGL_PIXEL_FORMAT_RGB_565, the red component would be in bits
* 11-15, the green component would be in 6-11 and the blue component
* would be in 1-5. Therefore the order in memory depends on the
* endianness of the system.
*
* When uploading a texture %COGL_PIXEL_FORMAT_ANY can be used as the
* internal format. Cogl will try to pick the best format to use
* internally and convert the texture data if necessary.
*
* Since: 0.8
*/
typedef enum /*< prefix=COGL_PIXEL_FORMAT >*/
{
COGL_PIXEL_FORMAT_ANY = 0,
COGL_PIXEL_FORMAT_A_8 = 1 | COGL_A_BIT,
COGL_PIXEL_FORMAT_RGB_565 = 4,
COGL_PIXEL_FORMAT_RGBA_4444 = 5 | COGL_A_BIT,
COGL_PIXEL_FORMAT_RGBA_5551 = 6 | COGL_A_BIT,
COGL_PIXEL_FORMAT_YUV = 7,
COGL_PIXEL_FORMAT_G_8 = 8,
COGL_PIXEL_FORMAT_RG_88 = 9,
COGL_PIXEL_FORMAT_RGB_888 = 2,
COGL_PIXEL_FORMAT_BGR_888 = (2 | COGL_BGR_BIT),
COGL_PIXEL_FORMAT_RGBA_8888 = (3 | COGL_A_BIT),
COGL_PIXEL_FORMAT_BGRA_8888 = (3 | COGL_A_BIT | COGL_BGR_BIT),
COGL_PIXEL_FORMAT_ARGB_8888 = (3 | COGL_A_BIT | COGL_AFIRST_BIT),
COGL_PIXEL_FORMAT_ABGR_8888 = (3 | COGL_A_BIT | COGL_BGR_BIT | COGL_AFIRST_BIT),
COGL_PIXEL_FORMAT_RGBA_1010102 = (13 | COGL_A_BIT),
COGL_PIXEL_FORMAT_BGRA_1010102 = (13 | COGL_A_BIT | COGL_BGR_BIT),
COGL_PIXEL_FORMAT_ARGB_2101010 = (13 | COGL_A_BIT | COGL_AFIRST_BIT),
COGL_PIXEL_FORMAT_ABGR_2101010 = (13 | COGL_A_BIT | COGL_BGR_BIT | COGL_AFIRST_BIT),
COGL_PIXEL_FORMAT_RGBA_8888_PRE = (3 | COGL_A_BIT | COGL_PREMULT_BIT),
COGL_PIXEL_FORMAT_BGRA_8888_PRE = (3 | COGL_A_BIT | COGL_PREMULT_BIT | COGL_BGR_BIT),
COGL_PIXEL_FORMAT_ARGB_8888_PRE = (3 | COGL_A_BIT | COGL_PREMULT_BIT | COGL_AFIRST_BIT),
COGL_PIXEL_FORMAT_ABGR_8888_PRE = (3 | COGL_A_BIT | COGL_PREMULT_BIT | COGL_BGR_BIT | COGL_AFIRST_BIT),
COGL_PIXEL_FORMAT_RGBA_4444_PRE = (COGL_PIXEL_FORMAT_RGBA_4444 | COGL_A_BIT | COGL_PREMULT_BIT),
COGL_PIXEL_FORMAT_RGBA_5551_PRE = (COGL_PIXEL_FORMAT_RGBA_5551 | COGL_A_BIT | COGL_PREMULT_BIT),
COGL_PIXEL_FORMAT_RGBA_1010102_PRE = (COGL_PIXEL_FORMAT_RGBA_1010102 | COGL_PREMULT_BIT),
COGL_PIXEL_FORMAT_BGRA_1010102_PRE = (COGL_PIXEL_FORMAT_BGRA_1010102 | COGL_PREMULT_BIT),
COGL_PIXEL_FORMAT_ARGB_2101010_PRE = (COGL_PIXEL_FORMAT_ARGB_2101010 | COGL_PREMULT_BIT),
COGL_PIXEL_FORMAT_ABGR_2101010_PRE = (COGL_PIXEL_FORMAT_ABGR_2101010 | COGL_PREMULT_BIT),
COGL_PIXEL_FORMAT_DEPTH_16 = (9 | COGL_DEPTH_BIT),
COGL_PIXEL_FORMAT_DEPTH_32 = (3 | COGL_DEPTH_BIT),
COGL_PIXEL_FORMAT_DEPTH_24_STENCIL_8 = (3 | COGL_DEPTH_BIT | COGL_STENCIL_BIT)
} CoglPixelFormat;
/**
* CoglFeatureFlags:
* @COGL_FEATURE_TEXTURE_YUV: ycbcr conversion support

View File

@ -35,6 +35,7 @@
#include <math.h>
#include <cogl/cogl-defines.h>
#include <cogl/cogl-pixel-format.h>
#include "cogl-types.h"
#include <stdio.h>

View File

@ -764,55 +764,3 @@ _cogl_init (void)
initialized = TRUE;
}
}
/*
* Returns the number of bytes-per-pixel of a given format. The bpp
* can be extracted from the least significant nibble of the pixel
* format (see CoglPixelFormat).
*
* The mapping is the following (see discussion on bug #660188):
*
* 0 = undefined
* 1, 8 = 1 bpp (e.g. A_8, G_8)
* 2 = 3 bpp, aligned (e.g. 888)
* 3 = 4 bpp, aligned (e.g. 8888)
* 4-6 = 2 bpp, not aligned (e.g. 565, 4444, 5551)
* 7 = undefined yuv
* 9 = 2 bpp, aligned
* 10 = undefined
* 11 = undefined
* 12 = 3 bpp, not aligned
* 13 = 4 bpp, not aligned (e.g. 2101010)
* 14-15 = undefined
*/
int
_cogl_pixel_format_get_bytes_per_pixel (CoglPixelFormat format)
{
int bpp_lut[] = { 0, 1, 3, 4,
2, 2, 2, 0,
1, 2, 0, 0,
3, 4, 0, 0 };
return bpp_lut [format & 0xf];
}
/* Note: this also refers to the mapping defined above for
* _cogl_pixel_format_get_bytes_per_pixel() */
gboolean
_cogl_pixel_format_is_endian_dependant (CoglPixelFormat format)
{
int aligned_lut[] = { -1, 1, 1, 1,
0, 0, 0, -1,
1, 1, -1, -1,
0, 0, -1, -1};
int aligned = aligned_lut[format & 0xf];
_COGL_RETURN_VAL_IF_FAIL (aligned != -1, FALSE);
/* NB: currently checking whether the format components are aligned
* or not determines whether the format is endian dependent or not.
* In the future though we might consider adding formats with
* aligned components that are also endian independant. */
return aligned;
}

View File

@ -64,6 +64,7 @@
#include <cogl/cogl-matrix.h>
#include <cogl/cogl-matrix-stack.h>
#include <cogl/cogl-offscreen.h>
#include <cogl/cogl-pixel-format.h>
#include <cogl/cogl-primitives.h>
#include <cogl/cogl-texture.h>
#include <cogl/cogl-types.h>

View File

@ -88,6 +88,7 @@ cogl_headers = [
'cogl-pipeline.h',
'cogl-pipeline-state.h',
'cogl-pipeline-layer-state.h',
'cogl-pixel-format.h',
'cogl-primitives.h',
'cogl-texture.h',
'cogl-texture-2d.h',
@ -233,6 +234,7 @@ cogl_sources = [
'cogl-display.c',
'cogl-driver.h',
'cogl.c',
'cogl-pixel-format.c',
'cogl-object-private.h',
'cogl-object.h',
'cogl-object.c',