Type: info
         Title: tools/diagnose_ex.h, vcl/sysdata.hxx, css::rendering::*
Effective from: CWS canvas05 (in to-be m22)

*Summary*
--------
tools/diagnose_ex.h: now contains a set of debug macros that combine
programmatic error signalling (throwing or returning false), and
debug-mode logging

vcl/sysdata.hxx: the structs got a few more members to faithfully
transport system surface data out of and into VCL

css::rendering::*: quite some changes there - among others, the
color space/color conversion API is now in usable state

*Description*
-------------

tools/diagnose_ex.h:

ENSURE_ARG_OR_THROW(c, m)            - throws illegal args exception on c being 
false
ENSURE_ARG_OR_THROW2(c, m, ifc, arg) - same, but passes on ifc as source of 
exception
                                       and takes # of arg that was invalid
ENSURE_OR_THROW(c, m)                - throws runtime exception on c being false
ENSURE_OR_THROW2(c, m, ifc)          - same, but passes on ifc as source of 
exception
ENSURE_OR_RETURN(c, m)               - returns false on c being false

Additionally, in OSL_DEBUG_LEVEL>0 builds, an OSL debug message is
issued in the error cases.

vcl/sysdata.hxx:

Basically, enhanced SystemGraphicsData with more members to be able
to transport VirtualDevice surfaces back&forth from VCL. Added
screen number also to SystemEnvData, otherwise multi-screen
scenarios on canvas triggered BadMatch errors occasionally.

css::rendering::XColorSpace,
css::rendering::XIntegerBitmapColorSpace:

Now, every color in the rendering API is to be interpreted relative
to a color space. XColorSpace provides generic methods to convert
between color spaces instances, and to the special s(A)RGB color
space. XIntegerBitmapColorSpace extends that with information about
bitwise color-layout (needed for bitmaps, where color often is
bit-packed)

css::rendering::BlendMode:

PDF-compatible blend modes (how to blend color with alpha against
another color with alpha)

css::rendering::X*ReadOnlyBitmap:

All bitmap interfaces now have an intermediate interface that only
provides read-only access to bitmap data - this allows for quite
(memory-)efficient XBitmap* implementations, where the data is e.g.
only generated on-demand, and avoids the
half-of-the-methods-return-an-error hack that was used before.

service css.rendering.Canvas.*,
service css.rendering.SpriteCanvas.*:

Now, there are two groups of canvas implementations - the
SpriteCanvas should be used for stuff like the slideshow, it's
optimized for animated content & does double-buffering. The Canvas
can be used with plain VCL windows & vdevs, and should intermix
smoothly with rendering to the plain OutputDevice.
The org.openoffice.Office.Canvas config node lists the currently
available implementations.
You should normally be just fine with requesting your canvas via
OutputDevice::GetCanvas() or Window::GetSpriteCanvas().

I intent to write up some howto on direct canvas instantiation on
the wiki: http://wiki.services.openoffice.org/wiki/Canvas

Send feedback to [EMAIL PROTECTED]

Cheers,

-- Thorsten

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to