|author||Thorsten Behrens <firstname.lastname@example.org>||2012-01-31 01:04:10 +0100|
|committer||Thorsten Behrens <email@example.com>||2013-10-07 17:33:45 +0200|
XCanvas does no longer imply XBitmapCanvas
Remove the implication that XCanvas IS-A XBitmapCanvas, i.e. one can access underlying pixels. That's a preparation for display-list based canvas implementations, and was a rather silly assumption in the first place. Also fixes up all client sites. Change-Id: I7a3d6f68ef46fe94b23cce7759cc0b8b6ca4dae9
Diffstat (limited to 'offapi')
1 files changed, 5 insertions, 6 deletions
diff --git a/offapi/com/sun/star/rendering/XSpriteCanvas.idl b/offapi/com/sun/star/rendering/XSpriteCanvas.idl
index eb98a4f3e830..f15b02b8efeb 100644
@@ -30,7 +30,7 @@ interface XSprite;
-/** Specialization of a XBitmapCanvas, where moving, animated objects
+/** Specialization of a XCanvas, where moving, animated objects
(called sprites) are supported.<p>
@attention The screen output of canvas drawing operations is
@@ -44,9 +44,9 @@ interface XCustomSprite;
(because there's a defined moment in time where content display
can happen, namely the XBufferController::showBuffer()) call. If
you don't need sprite functionality, and don't want the
- updateScreen hassle, simply use the XBitmapCanvas.
+ updateScreen hassle, simply use the XCanvas.
-interface XSpriteCanvas : XBitmapCanvas
+interface XSpriteCanvas : XCanvas
/** Create a sprite object from the specified animation
sequence. A sprite is a back-buffered object with its own,
@@ -98,9 +98,8 @@ interface XSpriteCanvas : XBitmapCanvas
The cloned sprite always shows the same content as its
- original. Furthermore, cloned copies of a hidden original are
- never visible, although cloned copies of a visible original
- can of course be invisible.
+ original, but of course the sprite position, visibility, alpha
+ etc. can be modified independently.
The original sprite to copy the content from. This sprite must