git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/back/trunk@29357 72102866-910b-0410-8b05-ffd578937521
This commit is contained in:
wlux 2010-01-22 08:16:50 +00:00
parent d58bec4f8a
commit d2e8790c6f
5 changed files with 32 additions and 1 deletions

View file

@ -638,6 +638,7 @@ draw_info_t ART_DI;
di.bytes_per_pixel = DI.bytes_per_pixel;
di.inline_alpha = DI.inline_alpha;
di.inline_alpha_ofs = DI.inline_alpha_ofs;
di.byte_order_from_client = NO;
ASSIGN(wi, [XWindowBuffer windowBufferForWindow: window depthInfo: &di]);
}

View file

@ -53,6 +53,8 @@
di.bytes_per_pixel = 4;
di.inline_alpha = YES;
di.inline_alpha_ofs = 0;
/* The cairo image surface uses the client's byte order (cf. bug #28590). */
di.byte_order_from_client = YES;
ASSIGN(wi, [XWindowBuffer windowBufferForWindow: GSWINDEVICE depthInfo: &di]);

View file

@ -389,6 +389,22 @@ no_xshm:
wi->window->xframe.size.height,
8, 0);
/* Normally, the data of an XImage is saved with the X server's
byte order. However, some backends (notably cairo) use the
native byte order of the client for the backend image. Since
XCreateImage sets up the image with the X server's byte order,
we must correct the byte order for those backends. Otherwise,
GNUstep applications would display wrong colors on an X server
that is running on a machine with a different byte order than
the client (bug #28590). */
if (wi->DI.byte_order_from_client)
{
#if GS_WORDS_BIGENDIAN
wi->ximage->byte_order = MSBFirst;
#else
wi->ximage->byte_order = LSBFirst;
#endif
}
wi->ximage->data = malloc(wi->ximage->height * wi->ximage->bytes_per_line);
if (!wi->ximage->data)
{