This method is useful for e.g. fading in/out of animations.

Please note that if this sprite is not animated, the associated XSpriteCanvas does not update changed sprites automatically, but has to be told to do so via XSpriteCanvas::updateScreen().

The position specified here is first transformed by the combined view and render transformation. The resulting position is then used as the output position (also in device coordinates) of the rendered sprite content.

Please note that if this sprite is not animated, the associated ::XSpriteCanva does not update changed sprites automatically, but has to be told to do so via XSpriteCanvas::updateScreen().

The given transformation matrix locally transforms the sprite shape. If this transformation contains translational components, be aware that sprite content moved beyond the sprite area (a box from (0,0) to (spriteWidth,spriteHeight)) might (but need not) be clipped. Use XSprite::move to change the sprite location on screen. The canvas implementations are free, if they have a cached representation of the sprite at hand, to transform only this cached representation (e.g. a bitmap), instead of re-rendering the sprite from first principles. This is usually the case for an implementation of a XCustomSprite interface, since it typically has no other cached pictorial information at hand.

Please note that if this sprite is not animated, the associated XSpriteCanvas does not update changed sprites automatically, but has to be told to do so via XSpriteCanvas::updateScreen().

The given clip poly-polygon is always interpreted in device coordinate space. As the sprite has its own local coordinate system, with its origin on screen being equal to its current position, the clip poly-polygon's origin will always coincide with the sprite's origin. Furthermore, if any sprite transformation is set via transform(), the clip is subject to this transformation, too. The implementation is free, if it has a cached representation of the sprite at hand, to clip-output only this cached representation (e.g. a bitmap), instead of re-rendering the sprite from first principles. This is usually the case for an implementation of a XCustomSprite interface, since it typically has no other cached pictorial information at hand.

Please note that if this sprite is not animated, the associated XSpriteCanvas does not update changed sprites automatically, but has to be told to do so via XSpriteCanvas::updateScreen().

Specifying an empty interface denotes no clipping, i.e. everything contained in the sprite will be visible (subject to device-dependent constraints, of course). Specifying an empty XPolyPolygon2D, i.e. a poly-polygon containing zero polygons, or an XPolyPolygon2D with any number of empty sub-polygons, denotes the NULL clip. That means, nothing from the sprite will be visible.

The sprite priority determines the order of rendering relative to all other sprites of the associated canvas. The higher the priority, the later will the sprite be rendered, or, in other words, the closer to the screen surface the sprite is shown.

This method makes the sprite visible on the canvas it was created on.

This method makes the sprite invisible.