A graphics port.
A keyword, or
One of the keywords
, or a boolean.
function loads an image identified by
using the image load function registered with it. It returns an image object with the representation slot initialized. The
argument specifies a graphics port used to identify the library. It also specifies the resource in which colors are defined and if necessary allocated for the image. If
is in the table but the translation is not an external image, and the image loader returns an external image as the second value, that external image replaces the translation in the table. The default value of
can be an image, which is just associated with the port
and returned if it is a Plain Image or if
. Otherwise a new Plain Image object is returned, as described below.
The cache argument controls whether the image translation is cached. See the convert-external-image function for more details.
that the image is in a particular graphics format. Currently the only recognised value is
, which means the image is a Bitmap. Other values of
to load the image according to the file type of
denotes a file, as described for read-external-image. See the Graphics Ports chapter in the
CAPI User Guide
for a discussion of image handling. The default value of
The image is not editable.
The image is editable, but does not have an alpha channel if the source of the image has an alpha channel (for example, a TIFF file with alpha channel).
The image is editable and has an alpha channel. It will be fully opaque when loading files without an alpha channel.
Given an image my-image , call
(load-image port my-image :editable t)
Normally the image is freed automatically, when gp is destroyed. However there are circumstances where you need to explicitly free an image, for example when you want it to go away before the port. If the image is not freed, a memory leak occurs.
must already be created at the time
is called. If you need to delay loading the image, for example if you are computing the image dynamically, then you can call
of the port or even in its first
In LispWorks 4.4 there is a keyword argument
with the same effect as
is still accepted in LispWorks 6.1 for backwards compatibility, but you should now use
CAPI Reference Manual - 15 Dec 2011