<html> <head> <title>Interface XGraphicDevice</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <link rel="stylesheet" type="text/css" href="../../../../idl.css"> </head> <body> <div id="adc-idlref"> <a name="_top_"> </a><table class="navimain" border="0" cellpadding="3"> <tr> <td class="navimain"><a href="../module-ix.html" class="navimain">Overview</a></td> <td class="navimain"><a href="module-ix.html" class="navimain">Module</a></td> <td class="navimain"><a href="XGraphicDevice-xref.html" class="navimain">Use</a></td> <td class="navimainnone">Devguide</td> <td class="navimain"><a href="../../../../index-files/index-1.html" class="navimain">Index</a></td> </tr> </table> <table class="navisub" border="0" cellpadding="0"> <tr> <td class="navisub"><a href="#MethodsSummary" class="navisub">Methods' Summary</a></td> <td class="navisub">Attributes' Summary</td> <td class="navisub"><a href="#MethodsDetails" class="navisub">Methods' Details</a></td> <td class="navisub">Attributes' Details</td> </tr> </table> <hr> <table border="0" width="100%" cellpadding="5" cellspacing="3" class="title-table" style="margin-bottom:6pt;"> <tr> <td><p class="namechain"><a href="../../../../module-ix.html" class="namechain">::</a> <a href="../../../module-ix.html" class="namechain">com</a> :: <a href="../../module-ix.html" class="namechain">sun</a> :: <a href="../module-ix.html" class="namechain">star</a> :: <a href="module-ix.html" class="namechain">rendering</a> :: </p> </td> </tr> <tr> <td class="title"><table class="title-table" width="99%"> <tr> <td width="25%" class="title2">unpublished </td> <td width="50%" class="title">interface XGraphicDevice</td> <td width="*"/></tr> </table> </td> </tr> <tr> <td/></tr> <tr> <td><dl> <dt><b>Usage Restrictions</b></dt> <dd><i>not published</i></dd> <dt><b>Description</b></dt> <dd>This interface provides access to a graphic device, such as a printer, or a screen device. Every canvas (</dd> <dt><b>See also</b></dt> <dd>XCanvas)<br> has exactly one associated graphic device, into which its output is rendered. For a typical windowing system, the graphic device is equivalent to a distinct OS window, with it's own clipped output area, fullscreen and double-buffering attributes. That is, even if one can have multiple canvases per system window, they all share the same graphic device and thus e.g. fullscreen state. If the OS restrictions are in such a way that fullscreen or double-buffering is screen-exclusive, i.e. that per screen, only one object can have this state, it might even be that all windows on the screen share a common graphic device. </dd> </dl> </td> </tr> </table> <hr> <a name="MethodsSummary"/><table border="1" width="100%" cellpadding="5" cellspacing="0" class="subtitle"> <tr> <td class="subtitle" colspan="2">Methods' Summary</td> </tr> <tr> <td class="imsum_left"><a href="#getBufferController">getBufferController</a></td> <td class="imsum_right">Query the controller for multi buffering functionality on this graphic device. If there is no such functionality available, the NULL reference is returned. </td> </tr> <tr> <td class="imsum_left"><a href="#getDeviceColorSpace">getDeviceColorSpace</a></td> <td class="imsum_right">Query the color space interface for this graphic device. This is to be used when interpreting or setting device color values. </td> </tr> <tr> <td class="imsum_left"><a href="#getPhysicalResolution">getPhysicalResolution</a></td> <td class="imsum_right">Query the physical resolution of the device in pixel per millimeter. A special floating point value of +infinity here indicates "unknown", i.e. at the time of rendering undetermined or possibly infinite resolution along the corresponding direction. </td> </tr> <tr> <td class="imsum_left"><a href="#getPhysicalSize">getPhysicalSize</a></td> <td class="imsum_right">Query the physical dimensions of the device in millimeter. A special floating point value of +infinity here indicates "unknown", i.e. at the time of rendering undetermined or possibly infinite resolution along the corresponding direction. </td> </tr> <tr> <td class="imsum_left"><a href="#createCompatibleLinePolyPolygon">createCompatibleLinePolyPolygon</a></td> <td class="imsum_right">Create a line poly-polygon which can internally use device-optimized representations already. </td> </tr> <tr> <td class="imsum_left"><a href="#createCompatibleBezierPolyPolygon">createCompatibleBezierPolyPolygon</a></td> <td class="imsum_right">Create a Bezier poly-polygon which can internally use device-optimized representations already. </td> </tr> <tr> <td class="imsum_left"><a href="#createCompatibleBitmap">createCompatibleBitmap</a></td> <td class="imsum_right">Create a bitmap whose memory layout and sample model is compatible to the graphic device. </td> </tr> <tr> <td class="imsum_left"><a href="#createVolatileBitmap">createVolatileBitmap</a></td> <td class="imsum_right">Create a volatile bitmap that is usable with this graphic device. A volatile bitmap's difference in comparison to a plain bitmap (e.g. generated via createCompatibleBitmap()) is the fact that its content might vanish at any point in time (making any operation with them produce a <a href="VolatileContentDestroyedException.html">VolatileContentDestroyedException</a>). The benefit, on the other hand, is that they might be easy to hardware-accelerate on certain platforms, without the need to keep a safety copy of the content internally. </td> </tr> <tr> <td class="imsum_left"><a href="#createCompatibleAlphaBitmap">createCompatibleAlphaBitmap</a></td> <td class="imsum_right">Create a bitmap with alpha channel whose memory layout and sample model is compatible to the graphic device. </td> </tr> <tr> <td class="imsum_left"><a href="#createVolatileAlphaBitmap">createVolatileAlphaBitmap</a></td> <td class="imsum_right">Create a volatile bitmap with alpha channel that is usable with this graphic device. A volatile bitmap's difference in comparison to a plain bitmap (e.g. generated via createCompatibleBitmap()) is the fact that its content might vanish at any point in time (making any operation with them produce a <a href="VolatileContentDestroyedException.html">VolatileContentDestroyedException</a>). The benefit, on the other hand, is that they might be easy to hardware-accelerate on certain platforms, without the need to keep a safety copy of the content internally. </td> </tr> <tr> <td class="imsum_left"><a href="#getParametricPolyPolygonFactory">getParametricPolyPolygonFactory</a></td> <td class="imsum_right">Get a reference to this device's parametric polygon factory. </td> </tr> <tr> <td class="imsum_left"><a href="#hasFullScreenMode">hasFullScreenMode</a></td> <td class="imsum_right">Tells whether this graphic device has a full screen mode, i.e. whether a window can cover the whole screen exclusively. </td> </tr> <tr> <td class="imsum_left"><a href="#enterFullScreenMode">enterFullScreenMode</a></td> <td class="imsum_right">Enter or leave the fullscreen mode, if possible. The return value denotes the success of the operation. @attention depending on the underlying operating system, fullscreen mode can be left without a enterFullScreenMode( false ) call. </td> </tr> </table> <a name="MethodsDetails"/><table border="1" width="100%" cellpadding="5" cellspacing="0" class="subtitle"> <tr> <td class="subtitle">Methods' Details</td> </tr> <tr> <td class="imdetail"><a name="getBufferController" class="membertitle">getBufferController</a><table border="0" width="96%" cellpadding="5" cellspacing="0" class="table-in-method" bgcolor="#ffffff" align="center"> <tr> <td><table class="table-in-method" border="0"> <tr> <td valign="top" colspan="3"><a href="XBufferController.html">XBufferController</a></td> </tr> <tr> <td valign="top"><b>getBufferController</b>();</td> </tr> </table> <hr> <dl> <dt><b>Description</b></dt> <dd>Query the controller for multi buffering functionality on this graphic device. If there is no such functionality available, the NULL reference is returned. </dd> </dl> </td> </tr> </table> </td> </tr> <tr> <td class="imdetail"><a name="getDeviceColorSpace" class="membertitle">getDeviceColorSpace</a><table border="0" width="96%" cellpadding="5" cellspacing="0" class="table-in-method" bgcolor="#ffffff" align="center"> <tr> <td><table class="table-in-method" border="0"> <tr> <td valign="top" colspan="3"><a href="XColorSpace.html">XColorSpace</a></td> </tr> <tr> <td valign="top"><b>getDeviceColorSpace</b>();</td> </tr> </table> <hr> <dl> <dt><b>Description</b></dt> <dd>Query the color space interface for this graphic device. This is to be used when interpreting or setting device color values. </dd> </dl> </td> </tr> </table> </td> </tr> <tr> <td class="imdetail"><a name="getPhysicalResolution" class="membertitle">getPhysicalResolution</a><table border="0" width="96%" cellpadding="5" cellspacing="0" class="table-in-method" bgcolor="#ffffff" align="center"> <tr> <td><table class="table-in-method" border="0"> <tr> <td valign="top" colspan="3">::com::sun::star::<a href="../geometry/module-ix.html">geometry</a>::<a href="../geometry/RealSize2D.html">RealSize2D</a></td> </tr> <tr> <td valign="top"><b>getPhysicalResolution</b>();</td> </tr> </table> <hr> <dl> <dt><b>Description</b></dt> <dd>Query the physical resolution of the device in pixel per millimeter. A special floating point value of +infinity here indicates "unknown", i.e. at the time of rendering undetermined or possibly infinite resolution along the corresponding direction. </dd> </dl> </td> </tr> </table> </td> </tr> <tr> <td class="imdetail"><a name="getPhysicalSize" class="membertitle">getPhysicalSize</a><table border="0" width="96%" cellpadding="5" cellspacing="0" class="table-in-method" bgcolor="#ffffff" align="center"> <tr> <td><table class="table-in-method" border="0"> <tr> <td valign="top" colspan="3">::com::sun::star::<a href="../geometry/module-ix.html">geometry</a>::<a href="../geometry/RealSize2D.html">RealSize2D</a></td> </tr> <tr> <td valign="top"><b>getPhysicalSize</b>();</td> </tr> </table> <hr> <dl> <dt><b>Description</b></dt> <dd>Query the physical dimensions of the device in millimeter. A special floating point value of +infinity here indicates "unknown", i.e. at the time of rendering undetermined or possibly infinite resolution along the corresponding direction. </dd> <dt><b>See also</b></dt> <dd><a href="XBitmap.html">XBitmap</a>::<a href="XBitmap.html#getSize">getSize()</a></dd> </dl> </td> </tr> </table> </td> </tr> <tr> <td class="imdetail"><a name="createCompatibleLinePolyPolygon" class="membertitle">createCompatibleLinePolyPolygon</a><table border="0" width="96%" cellpadding="5" cellspacing="0" class="table-in-method" bgcolor="#ffffff" align="center"> <tr> <td><table class="table-in-method" border="0"> <tr> <td valign="top" colspan="3"><a href="XLinePolyPolygon2D.html">XLinePolyPolygon2D</a></td> </tr> <tr> <td valign="top"><b>createCompatibleLinePolyPolygon</b>(</td> <td valign="top">[in] sequence< sequence< ::com::sun::star::<a href="../geometry/module-ix.html">geometry</a>::<a href="../geometry/RealPoint2D.html">RealPoint2D</a> > ></td> <td valign="bottom"> points );</td> </tr> </table> <hr> <dl> <dt><b>Description</b></dt> <dd>Create a line poly-polygon which can internally use device-optimized representations already. </dd> <dt><b>Parameter points</b></dt> <dd>The points of the poly-polygon, in a separate array for every polygon. </dd> </dl> </td> </tr> </table> </td> </tr> <tr> <td class="imdetail"><a name="createCompatibleBezierPolyPolygon" class="membertitle">createCompatibleBezierPolyPolygon</a><table border="0" width="96%" cellpadding="5" cellspacing="0" class="table-in-method" bgcolor="#ffffff" align="center"> <tr> <td><table class="table-in-method" border="0"> <tr> <td valign="top" colspan="3"><a href="XBezierPolyPolygon2D.html">XBezierPolyPolygon2D</a></td> </tr> <tr> <td valign="top"><b>createCompatibleBezierPolyPolygon</b>(</td> <td valign="top">[in] sequence< sequence< ::com::sun::star::<a href="../geometry/module-ix.html">geometry</a>::<a href="../geometry/RealBezierSegment2D.html">RealBezierSegment2D</a> > ></td> <td valign="bottom"> points );</td> </tr> </table> <hr> <dl> <dt><b>Description</b></dt> <dd>Create a Bezier poly-polygon which can internally use device-optimized representations already. </dd> <dt><b>Parameter points</b></dt> <dd>The points of the poly-polygon, in a separate array for every polygon. </dd> </dl> </td> </tr> </table> </td> </tr> <tr> <td class="imdetail"><a name="createCompatibleBitmap" class="membertitle">createCompatibleBitmap</a><table border="0" width="96%" cellpadding="5" cellspacing="0" class="table-in-method" bgcolor="#ffffff" align="center"> <tr> <td><table class="table-in-method" border="0"> <tr> <td valign="top" colspan="3"><a href="XBitmap.html">XBitmap</a></td> </tr> <tr> <td valign="top"><b>createCompatibleBitmap</b>(</td> <td valign="top">[in] ::com::sun::star::<a href="../geometry/module-ix.html">geometry</a>::<a href="../geometry/IntegerSize2D.html">IntegerSize2D</a></td> <td valign="bottom"> size )</td> </tr> <tr> <td valign="top" align="right">raises( </td> <td valign="top" colspan="2">::com::sun::star::<a href="../lang/module-ix.html">lang</a>::<a href="../lang/IllegalArgumentException.html">IllegalArgumentException</a> );</td> </tr> </table> <hr> <dl> <dt><b>Description</b></dt> <dd>Create a bitmap whose memory layout and sample model is compatible to the graphic device. </dd> <dt><b>Parameter size</b></dt> <dd>Size of the requested bitmap in pixel. Both components of the size must be greater than 0 </dd> </dl> </td> </tr> </table> </td> </tr> <tr> <td class="imdetail"><a name="createVolatileBitmap" class="membertitle">createVolatileBitmap</a><table border="0" width="96%" cellpadding="5" cellspacing="0" class="table-in-method" bgcolor="#ffffff" align="center"> <tr> <td><table class="table-in-method" border="0"> <tr> <td valign="top" colspan="3"><a href="XVolatileBitmap.html">XVolatileBitmap</a></td> </tr> <tr> <td valign="top"><b>createVolatileBitmap</b>(</td> <td valign="top">[in] ::com::sun::star::<a href="../geometry/module-ix.html">geometry</a>::<a href="../geometry/IntegerSize2D.html">IntegerSize2D</a></td> <td valign="bottom"> size )</td> </tr> <tr> <td valign="top" align="right">raises( </td> <td valign="top" colspan="2">::com::sun::star::<a href="../lang/module-ix.html">lang</a>::<a href="../lang/IllegalArgumentException.html">IllegalArgumentException</a> );</td> </tr> </table> <hr> <dl> <dt><b>Description</b></dt> <dd>Create a volatile bitmap that is usable with this graphic device. A volatile bitmap's difference in comparison to a plain bitmap (e.g. generated via createCompatibleBitmap()) is the fact that its content might vanish at any point in time (making any operation with them produce a <a href="VolatileContentDestroyedException.html">VolatileContentDestroyedException</a>). The benefit, on the other hand, is that they might be easy to hardware-accelerate on certain platforms, without the need to keep a safety copy of the content internally. </dd> <dt><b>Parameter size</b></dt> <dd>Size of the requested bitmap in pixel. Both components of the size must be greater than 0 </dd> </dl> </td> </tr> </table> </td> </tr> <tr> <td class="imdetail"><a name="createCompatibleAlphaBitmap" class="membertitle">createCompatibleAlphaBitmap</a><table border="0" width="96%" cellpadding="5" cellspacing="0" class="table-in-method" bgcolor="#ffffff" align="center"> <tr> <td><table class="table-in-method" border="0"> <tr> <td valign="top" colspan="3"><a href="XBitmap.html">XBitmap</a></td> </tr> <tr> <td valign="top"><b>createCompatibleAlphaBitmap</b>(</td> <td valign="top">[in] ::com::sun::star::<a href="../geometry/module-ix.html">geometry</a>::<a href="../geometry/IntegerSize2D.html">IntegerSize2D</a></td> <td valign="bottom"> size )</td> </tr> <tr> <td valign="top" align="right">raises( </td> <td valign="top" colspan="2">::com::sun::star::<a href="../lang/module-ix.html">lang</a>::<a href="../lang/IllegalArgumentException.html">IllegalArgumentException</a> );</td> </tr> </table> <hr> <dl> <dt><b>Description</b></dt> <dd>Create a bitmap with alpha channel whose memory layout and sample model is compatible to the graphic device. </dd> <dt><b>Parameter size</b></dt> <dd>Size of the requested bitmap in pixel. Both components of the size must be greater than 0 </dd> </dl> </td> </tr> </table> </td> </tr> <tr> <td class="imdetail"><a name="createVolatileAlphaBitmap" class="membertitle">createVolatileAlphaBitmap</a><table border="0" width="96%" cellpadding="5" cellspacing="0" class="table-in-method" bgcolor="#ffffff" align="center"> <tr> <td><table class="table-in-method" border="0"> <tr> <td valign="top" colspan="3"><a href="XVolatileBitmap.html">XVolatileBitmap</a></td> </tr> <tr> <td valign="top"><b>createVolatileAlphaBitmap</b>(</td> <td valign="top">[in] ::com::sun::star::<a href="../geometry/module-ix.html">geometry</a>::<a href="../geometry/IntegerSize2D.html">IntegerSize2D</a></td> <td valign="bottom"> size )</td> </tr> <tr> <td valign="top" align="right">raises( </td> <td valign="top" colspan="2">::com::sun::star::<a href="../lang/module-ix.html">lang</a>::<a href="../lang/IllegalArgumentException.html">IllegalArgumentException</a> );</td> </tr> </table> <hr> <dl> <dt><b>Description</b></dt> <dd>Create a volatile bitmap with alpha channel that is usable with this graphic device. A volatile bitmap's difference in comparison to a plain bitmap (e.g. generated via createCompatibleBitmap()) is the fact that its content might vanish at any point in time (making any operation with them produce a <a href="VolatileContentDestroyedException.html">VolatileContentDestroyedException</a>). The benefit, on the other hand, is that they might be easy to hardware-accelerate on certain platforms, without the need to keep a safety copy of the content internally. </dd> <dt><b>Parameter size</b></dt> <dd>Size of the requested bitmap in pixel. Both components of the size must be greater than 0 </dd> </dl> </td> </tr> </table> </td> </tr> <tr> <td class="imdetail"><a name="getParametricPolyPolygonFactory" class="membertitle">getParametricPolyPolygonFactory</a><table border="0" width="96%" cellpadding="5" cellspacing="0" class="table-in-method" bgcolor="#ffffff" align="center"> <tr> <td><table class="table-in-method" border="0"> <tr> <td valign="top" colspan="3">::com::sun::star::<a href="../lang/module-ix.html">lang</a>::<a href="../lang/XMultiServiceFactory.html">XMultiServiceFactory</a></td> </tr> <tr> <td valign="top"><b>getParametricPolyPolygonFactory</b>();</td> </tr> </table> <hr> <dl> <dt><b>Description</b></dt> <dd>Get a reference to this device's parametric polygon factory. </dd> <dt><b>Returns</b></dt> <dd>a reference to this device's parametric polygon factory. Although it is possible to use parametric polygons on all canvases, regardless of the associated graphic device, this is not advisable: each canvas implementation is free to internally generate optimized parametric polygons, which can be used more directly for e.g. texturing operations. <pre> Available services (all canvas implementations should provide this minimal set, though are free to add more; just check the getAvailableServiceNames() on the returned interface): - Gradients - all gradients need to support two construction parameters, "Colors" being a <Color>::sequence and "Stops" being a <double>::sequence. Both must have the same length, and at least two elements. See http://www.w3.org/TR/SVG11/pservers.html#GradientStops for the semantics of gradient stops and colors. Required gradient services: * "LinearGradient" - the gradient varies linearly between the given colors. without coordinate system transformation, the color interpolation happens in increasing x direction, and is constant in y direction. Equivalent to svg linear gradient http://www.w3.org/TR/SVG11/pservers.html#LinearGradients * "EllipticalGradient" - this gradient has zeroth color index in the middle, and varies linearly between center and final color. The services takes an additional parameter named "AspectRatio" of ::double (width divided by height), if this aspect ratio is 1, the gradient is circular. If it's not 1, the gradient is elliptical, with the special twist that the aspect ratio is maintained also for the center color: the gradient will not collapse into a single point, but become a line of center color. If "AspectRatio" is missing, or equal to 1, this gradient yields similar results as the svg radial gradient http://www.w3.org/TR/SVG11/pservers.html#RadialGradients * "RectangularGradient" - this gradient has zeroth color index in the middle, and varies linearly between center and final color via rectangular boxes around the center point. The services takes an additional parameter named "AspectRatio" of ::double (width divided by height), if this aspect ratio is 1, the gradient is quadratic. If it's not 1, the gradient is rectangular, with the special twist that the aspect ratio is maintained also for the center color: the gradient will not collapse into a single point, but become a line of center color. - Hatch patterns - Required hatch services: * "VerticalLineHatch" - this hatching consists of vertical lines * "OrthogonalLinesHatch" - this hatching consists of crossing vertical and horizontal lines * "ThreeCrossingLinesHatch" - this hatching consists of vertical and horizontal lines plus diagonal lines from left, top to bottom, right. * "FourCrossingLinesHatch" - this hatching consists of vertical and horizontal lines plus diagonal lines in both directions. </pre> </dd> </dl> </td> </tr> </table> </td> </tr> <tr> <td class="imdetail"><a name="hasFullScreenMode" class="membertitle">hasFullScreenMode</a><table border="0" width="96%" cellpadding="5" cellspacing="0" class="table-in-method" bgcolor="#ffffff" align="center"> <tr> <td><table class="table-in-method" border="0"> <tr> <td valign="top" colspan="3">boolean</td> </tr> <tr> <td valign="top"><b>hasFullScreenMode</b>();</td> </tr> </table> <hr> <dl> <dt><b>Description</b></dt> <dd>Tells whether this graphic device has a full screen mode, i.e. whether a window can cover the whole screen exclusively. </dd> </dl> </td> </tr> </table> </td> </tr> <tr> <td class="imdetail"><a name="enterFullScreenMode" class="membertitle">enterFullScreenMode</a><table border="0" width="96%" cellpadding="5" cellspacing="0" class="table-in-method" bgcolor="#ffffff" align="center"> <tr> <td><table class="table-in-method" border="0"> <tr> <td valign="top" colspan="3">boolean</td> </tr> <tr> <td valign="top"><b>enterFullScreenMode</b>(</td> <td valign="top">[in] boolean</td> <td valign="bottom"> bEnter );</td> </tr> </table> <hr> <dl> <dt><b>Description</b></dt> <dd>Enter or leave the fullscreen mode, if possible. The return value denotes the success of the operation. @attention depending on the underlying operating system, fullscreen mode can be left without a enterFullScreenMode( false ) call. </dd> </dl> </td> </tr> </table> </td> </tr> </table> <a href="#_top_">Top of Page</a><hr size="3"><p class="copyright" align="center">Copyright © 2000, 2012 LibreOffice contributors and/or their affiliates. All rights reserved.</p><p class="copyright" align="center">LibreOffice was created by The Document Foundation, based on OpenOffice.org, which is Copyright 2000, 2010 Oracle and/or its affiliates.</p><p class="copyright" align="center">The Document Foundation acknowledges all community members, please find more info <a href="http://www.libreoffice.org/about-us/credits/" target="_blank">at our website</a>.<p> </p><p class="copyright" align="center"><a href="http://www.libreoffice.org/privacy" target="_blank">Privacy Policy</a> | <a href="http://www.libreoffice.org/imprint" target="_blank">Impressum (Legal Info)</a> | Copyright information: The source code of LibreOffice is licensed under the GNU Lesser General Public License (<a href="http://www.libreoffice.org/download/license/" target="_blank">LGPLv3</a>). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our <a href="http://wiki.documentfoundation.org/TradeMark_Policy" target="_blank">trademark policy</a>.</p> </div> <!-- id="adc-idlref" --> </body> </html>
