Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!wuarchive!wugate!uunet!snorkelwacker!spdcc!xylogics!world!madd
From: madd@world.std.com (jim frost)
Newsgroups: comp.windows.x
Subject: Re: XImage
Message-ID: <1989Oct26.232459.9631@world.std.com>
Date: 26 Oct 89 23:24:59 GMT
References: <3048@marble.sw.mcc.com>
Reply-To: madd@world.UUCP (jim frost)
Organization: Software Tool & Die
Lines: 28

In article <3048@marble.sw.mcc.com> cheung@marble.sw.mcc.com (Po Cheung) writes:
|To invert an XImage, I can think of creating a pixmap of same size and
|depth, copying the image (with XPutImage and GXcopyInverted) into the 
|pixmap, and retrieving the image back from the pixmap (XGetImage). 
|
|Is this the right way?  Does it mean all graphics operations on images
|have to go through a pixmap?

No, you can do each of them yourself in the client with either
GetPixel/PutPixel or your own (presumably much faster) functions.  I
did the latter when creating my xloadimage program, mostly because X
supports very few image manipulations (which is as it should be, I
think).

The only problem with creating your own images manipulation routines
is that XImages might be in many different bit and byte orders.  I get
around this by using my own image format and setting up the XImage to
match (which works very well).

It's probably best to think of X as a display server and not an image
manipulation utility; it's good at displaying images but most of the
trivial image manipulation functions that it provides are really best
used as graphical operations with draw commands (eg GXcopyinverted
might be used to invert a menu option).

jim frost
software tool & die     "The World" Public Access Unix for the '90s
madd@std.com            +1 617-739-WRLD  24hrs {3,12,24}00bps