This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project gfxprim.git.
The branch, generate has been updated via 7d194009dcecc9c2d668bdd6f7add3cbf8bdd680 (commit) from 72f38ee0793386a9c792698c6f4b3a4a79ee1352 (commit)
Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below.
- Log ----------------------------------------------------------------- http://repo.or.cz/w/gfxprim.git/commit/7d194009dcecc9c2d668bdd6f7add3cbf8bdd...
commit 7d194009dcecc9c2d668bdd6f7add3cbf8bdd680 Author: Tomas Gavenciak gavento@ucw.cz Date: Wed Aug 17 12:12:09 2011 +0200
Added docs for pixel size and type
diff --git a/doc/pixel_types.txt b/doc/pixel_types.txt new file mode 100644 index 0000000..bf5acd8 --- /dev/null +++ b/doc/pixel_types.txt @@ -0,0 +1,56 @@ +Supported pixel sizes +--------------------- + +The default maximum size of a single pixel is 32 bits. The limitations would +be analoguous for other settings (8, 16 and 64). + +Pixel sizes 8, 16 and 32 are supported on all systems and generally very efficient +(assigment is used for all operations). 24 bpp is supported, but the operations may be +slightly slower. + +Pixel sizes 1, 2 and 4 depend on bit-endian setting and are supported on all systems. +Subcontext operations and blits may be slower in case of a different subpixel alignment. + +Pixel sizes not divisible by 8 and between 9 and 23 depend on the bit endian - +the endianity of the system must match the bit-endianity. The other combination +is not supported at all - it would be too complicated and probably very inefficient +to decode/encode. + +Pixel sizes between 25 and 31 are not supported at all, as these pixels might not fit +into a 32-bit byte-aligned window. + +The pixel sizes to be supported must be explicitely listed in the configuration file, +each including the bit-endian if required (see below). + +Supported pixel types +--------------------- + +The supported files are declared in the configuration file and must use only the declared +pixel sizes with bit-endians. RGB, monochrome and palette formats are supported, +all with optional alpha channel (the alpha support level for palette types is not decided yet). + +The pixel type + +System endianity +---------------- + +The library should work on both little-endian and big-endian systems. +Other variants than the standard (0123 and 3210) are not supported. + +In case of pixel sizes between 9 and 23 (except for 16), the system endianity must match the +selected bit endianity. It is safe to build the library with the disallowed combination +format, as long as it is not used (compile-time warning is generated). + +Bit-endianity +------------- + +With 1, 2 and 4 bpp formats, there are two possible orders of pixels within a byte, +both seen in the wild. The two are enumerated in `GP_BIT_ENDIAN`: + +`GP_BIT_ENDIAN_LE`:: + Less significant bits contain pixels with lower indices. + Also used for irrelevant bit-endian (8, 15, 24, 32bpp). +`GP_BIT_ENDIAN_BE`:: + More significant bits contain pixels with lower indices. + +
-----------------------------------------------------------------------
Summary of changes: doc/pixel_types.txt | 56 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 56 insertions(+), 0 deletions(-) create mode 100644 doc/pixel_types.txt
repo.or.cz automatic notification. Contact project admin jiri.bluebear.dluhos@gmail.com if you want to unsubscribe, or site admin admin@repo.or.cz if you receive no reply.