summaryrefslogtreecommitdiffstats
path: root/kdeui/kpixmapio.h
diff options
context:
space:
mode:
authorTimothy Pearson <kb9vqf@pearsoncomputing.net>2011-11-06 15:56:40 -0600
committerTimothy Pearson <kb9vqf@pearsoncomputing.net>2011-11-06 15:56:40 -0600
commite16866e072f94410321d70daedbcb855ea878cac (patch)
treeee3f52eabde7da1a0e6ca845fb9c2813cf1558cf /kdeui/kpixmapio.h
parenta58c20c1a7593631a1b50213c805507ebc16adaf (diff)
downloadtdelibs-e16866e072f94410321d70daedbcb855ea878cac.tar.gz
tdelibs-e16866e072f94410321d70daedbcb855ea878cac.zip
Actually move the kde files that were renamed in the last commit
Diffstat (limited to 'kdeui/kpixmapio.h')
-rw-r--r--kdeui/kpixmapio.h185
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__