XFixesGetCursorImage spec annoying/confusing...

[Christian Parpart]

Hi,

I'm currently coding a screen capture library, however, the proper cursor 
capturing wasn't that fun at all.

The following is a quote from the xfixes spec:

	The cursor image itself is returned as a single image at 32 bits per
	pixel with 8 bits of alpha in the most significant 8 bits of the
	pixel followed by 8 bits each of red, green and finally 8 bits of
	blue in the least significant 8 bits.  The color components are
	pre-multiplied with the alpha component.

Now, you do believe, hey, cool, you've per pixel 32bit, ARGB, and can iterate 
through them, unfortunately it won't that easy, especially when it comes to 
64bit architectures.

The next is a quote from /usr/include/X11/extensions/Xfixes.h

typedef struct {
    short       x, y;
    unsigned short  width, height;
    unsigned short  xhot, yhot;
    unsigned long   cursor_serial;
    unsigned long   *pixels;
#if XFIXES_MAJOR >= 2
    Atom            atom;           /* Version >= 2 only */
    const char      *name;          /* Version >= 2 only */
#endif
} XFixesCursorImage;

on a x86 I could easily copy the `pixels` structure either by iterating 
through it or via memcpy, which is said to be faster.
On an AMD64 now you can't do, because here the datatype long is 64bits long, 
not 32. which is quite confusing, because it is nothing stated in the xfixes 
spec about wether these pixels are stored packet 32bits, or depending on 
whatever size your `long` has.

So, is this the expected behavior, to have 64bit per pixel on at least AMD64?

I found it quite annoying, as I either didn't read it in the spec, nor got 
quickly rid of that "why draws my cursor just the half"-bug because of this 
long-vs-32bit datatype issue.


Thanks in advance,
Christian Parpart.









-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20070223/4e757535/attachment.pgp>