diff options
Diffstat (limited to 'kdeui/kpixmapio.h')
| -rw-r--r-- | kdeui/kpixmapio.h | 185 |
1 files changed, 0 insertions, 185 deletions
diff --git a/kdeui/kpixmapio.h b/kdeui/kpixmapio.h deleted file mode 100644 index 62bde1c35..000000000 --- a/kdeui/kpixmapio.h +++ /dev/null @@ -1,185 +0,0 @@ -/* vi: ts=8 sts=4 sw=4 - * - * - * This file is part of the KDE project, module tdeui. - * Copyright (C) 2000 Geert Jansen <jansen@kde.org> - * - * You can Freely distribute this program under the GNU Library General - * Public License. See the file "COPYING.LIB" for the exact licensing terms. - */ - -#ifndef __KPixmapIO_h_Included__ -#define __KPixmapIO_h_Included__ - -#include <kdelibs_export.h> - -class TQPixmap; -class TQImage; -class TQPoint; -class TQRect; -struct KPixmapIOPrivate; -/** - * @short Fast TQImage to/from TQPixmap conversion. - * @author Geert Jansen <jansen@kde.org> - * @version $Id$ - * - * KPixmapIO implements a fast path for TQPixmap to/from TQImage conversions. - * It uses the MIT-SHM shared memory extension for this. If this extension is - * not available, it will fall back to standard Qt methods. - * - * <b>Typical usage:</b>\n - * - * You can use KPixmapIO for load/saving pixmaps. - * - * \code - * KPixmapIO io; - * pixmap = io.convertToPixmap(image); - * image = io.convertToImage(pixmap); - * \endcode - * - * It also has functionality for partially updating/saving pixmaps, see - * putImage and getImage. - * - * <b>KPixmapIO vs. Qt speed comparison</b>\n - * - * Speed measurements were taken. These show that usage of KPixmapIO for - * images up to a certain threshold size, offers no speed advantage over - * the Qt routines. Below you can see a plot of these measurements. - * - * @image html kpixmapio-perf.png "Performance of KPixmapIO" - * - * The threshold size, amongst other causes, is determined by the shared - * memory allocation policy. If the policy is @p ShmDontKeep, the - * shared memory segment is discarded right after usage, and thus needs to - * be allocated before each transfer. This introduces a a setup penalty not - * present when the policy is @p ShmKeepAndGrow. In this case the - * shared memory segment is kept and resized when necessary, until the - * KPixmapIO object is destroyed. - * - * The default policy is @p ShmDontKeep. This policy makes sense when - * loading pixmaps once. The corresponding threshold is taken at 5.000 - * pixels as suggested by experiments. Below this threshold, KPixmapIO - * will not use shared memory and fall back on the Qt routines. - * - * When the policy is @p ShmKeepAndGrow, the threshold is taken at - * 2.000 pixels. Using this policy, you might want to use preAllocShm - * to pre-allocate a certain amount of shared memory, in order to avoid - * resizes. This allocation policy makes sense in a multimedia type - * application where you are constantly updating the screen. - * - * Above a couple times the threshold size, KPixmapIO's and Qt's speed become - * linear in the number of pixels, KPixmapIO being at least 2, and mostly around - * 4 times faster than Qt, depending on the screen and image depth. - * - * Speed difference seems to be the most at 16 bpp, followed by 32 and 24 - * bpp respectively. This can be explained by the relatively poor - * implementation of 16 bit RGB packing in Qt, while at 32 bpp we need to - * transfer more data, and thus gain more, than at 24 bpp. - * - * <b>Conclusion:</b>\n - * - * For large pixmaps, there's a definite speed improvement when using - * KPixmapIO. On the other hand, there's no speed improvement for small - * pixmaps. When you know you're only transferring small pixmaps, there's no - * point in using it. - */ - -class KDEUI_EXPORT KPixmapIO -{ -public: - KPixmapIO(); - ~KPixmapIO(); - - /** - * Convert an image to a pixmap. - * @param image The image to convert. - * @return The pixmap containing the image. - */ - TQPixmap convertToPixmap(const TQImage &image); - - /** - * Convert a pixmap to an image. - * @param pixmap The pixmap to convert. - * @return The image. - */ - TQImage convertToImage(const TQPixmap &pixmap); - - /** - * Bitblt an image onto a pixmap. - * @param dst The destination pixmap. - * @param dx Destination x offset. - * @param dy Destination y offset. - * @param src The image to load. - */ - void putImage(TQPixmap *dst, int dx, int dy, const TQImage *src); - - /** - * This function is identical to the one above. It only differs in the - * arguments it accepts. - */ - void putImage(TQPixmap *dst, const TQPoint &offset, const TQImage *src); - - /** - * Transfer (a part of) a pixmap to an image. - * @param src The source pixmap. - * @param sx Source x offset. - * @param sy Source y offset. - * @param sw Source width. - * @param sh Source height. - * @return The image. - */ - TQImage getImage(const TQPixmap *src, int sx, int sy, int sw, int sh); - - /** - * This function is identical to the one above. It only differs in the - * arguments it accepts. - */ - TQImage getImage(const TQPixmap *src, const TQRect &rect); - - /** - * Shared memory allocation policies. - */ - enum ShmPolicies { - ShmDontKeep, - ShmKeepAndGrow - }; - - /** - * Set the shared memory allocation policy. See the introduction for - * KPixmapIO for a discussion. - * @param policy The alloction policy. - */ - void setShmPolicy(int policy); - - /** - * Pre-allocate shared memory. KPixmapIO will be able to transfer images - * up to this size without resizing. - * @param size The size of the image in @p pixels. - */ - void preAllocShm(int size); - -private: - /* - * Supported XImage byte orders. The notation ARGB means bytes - * containing A:R:G:B succeed in memory. - */ - enum ByteOrders { - bo32_ARGB, bo32_BGRA, bo24_RGB, bo24_BGR, - bo16_RGB_565, bo16_BGR_565, bo16_RGB_555, - bo16_BGR_555, bo8 - }; - - bool m_bShm; - bool initXImage(int w, int h); - void doneXImage(); - bool createXImage(int w, int h); - void destroyXImage(); - bool createShmSegment(int size); - void destroyShmSegment(); - void convertToXImage(const TQImage &); - TQImage convertFromXImage(); -private: - KPixmapIOPrivate* d; -}; - -#endif // __KPixmapIO_h_Included__ |