[Kde-graphics-devel] Status update
Lars Knoll
lars at trolltech.com
Tue Jan 4 11:07:35 CET 2005
On Tuesday 04 January 2005 00:17, Mosfet wrote:
> No, you cannot depend on pixmaps being any particular depth. Right now on
> my machine it's not 24bpp, and I'm running a brand new X.org CVS checkout.
>
> I use a 16bpp video mode with LSB byte order, so that's what pixmaps are.
> Pixmaps will always have the same color depth as the visual you are using.
>
> A lot of non-X11 geeks don't realize what happens when you convert an image
> to a pixmap. No matter if your using Qt, MImage, ImageMagick, or Imlib you
> first convert the toolkit's image into an XImage. An XImage is a
> scanline-based image but is in the byte order and depth of the X server's
> visual. This means if the X server is 16bpp the XImage will be 16bpp or
> below.
>
> Then you place the XImage on the server, preferably with MIT-SHM. What you
> get back is a X11 pixmap handle to the image. X11 pixmaps are really only
> integer ID's to an XImage on the X server. You can't directly access the
> scanlines anymore. If you want to directly access the bits you need to copy
> the image back to your client, (convert the pixmap to an image), but you
> have to remember it's been truncated to whatever depth your X11 visual is.
>
> That's why I don't like programs that convert an image to a pixmap to
> display it, then convert it back to an image to edit it. You'll end up
> loosing color resolution. You should keep the image around in your client
> and just convert to pixmaps to display it.
For high quality graphics apps this is correct. However for at least 95% of
the use cases you don't care about the source image anymore and it would just
be a memory hog on the client side.
Qt is about making things as easy as possible for the 95% of the use cases and
making the other 5% possible, so it would IMO be a mistake to cache the
source image in general. Also as soon as someone opens a painter on the
pixmap, you'd have to throw away the source anyways.
Cheers,
Lars
More information about the Kde-graphics-devel
mailing list