//Auto-generated by kalyptus. DO NOT EDIT. package org.kde.koala; import org.kde.qt.Qt; import org.kde.qt.TQRect; import org.kde.qt.QtSupport; import org.kde.qt.TQPixmap; import org.kde.qt.TQImage; import org.kde.qt.TQPoint; /** 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.
KPixmapIO io; pixmap = io.convertToPixmap(image); image = io.convertToImage(pixmap);It also has functionality for partially updating/saving pixmaps, see putImage and getImage. KPixmapIO vs. Qt speed comparison\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. The threshold size, amongst other causes, is determined by the shared memory allocation policy. If the policy is
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 ShmKeepAndGrow.
In this case the
shared memory segment is kept and resized when necessary, until the
KPixmapIO object is destroyed.
The default policy is 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 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.
pixels.
@short Pre-allocate shared memory.
*/
public native void preAllocShm(int size);
/** Deletes the wrapped C++ instance */
protected native void finalize() throws InternalError;
/** Delete the wrapped C++ instance ahead of finalize() */
public native void dispose();
/** Has the wrapped C++ instance been deleted? */
public native boolean isDisposed();
}