<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> | |
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office"> | |
<head> | |
<meta http-equiv="Content-Language" content="en-us" /> | |
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> | |
<title>Welcome to BLTsville</title> | |
<style type="text/css"> | |
.cmd_line { | |
background: #000; | |
color: #fff; | |
padding: 10px; | |
} | |
.inline_code { | |
font-family: "Courier New", Courier, monospace; | |
font-size: small; | |
} | |
.code_block { | |
margin-left: 40px; | |
font-family: "Courier New", Courier, monospace; | |
font-size: small; | |
} | |
.small_code_block_in_table { | |
font-family: "Courier New", Courier, monospace; | |
font-size: x-small; | |
} | |
.small_code_block { | |
font-family: "Courier New", Courier, monospace; | |
font-size: x-small; | |
margin-left: 40px; | |
} | |
.underline_code { | |
font-family: "Courier New", Courier, monospace; | |
font-size: small; | |
text-decoration: underline; | |
} | |
.Code_Header { | |
font-size: xx-large; | |
font-weight: bold; | |
text-align: left; | |
font-family: "Courier New", Courier, monospace; | |
} | |
.Code_Header_2 { | |
font-size: x-large; | |
font-weight: bold; | |
text-align: left; | |
font-family: "Courier New", Courier, monospace; | |
} | |
.Code_Header_3 { | |
font-size: large; | |
font-weight: bold; | |
text-align: left; | |
font-family: "Courier New", Courier, monospace; | |
} | |
.imponly { | |
border: thin solid #666666; | |
margin-left: 40px; | |
background-color: #E5E5E5; | |
font-family: Arial, Helvetica, sans-serif; | |
color: #333333; | |
} | |
.Header1 { | |
margin: 0px 0 0 0; | |
font-size: xx-large; | |
font-weight: bold; | |
text-align: left; | |
line-height: normal; | |
background-color: #E0E0E0; | |
} | |
.Header2 { | |
font-size: xx-large; | |
font-weight: bold; | |
margin: 0px; | |
line-height: 100%; | |
} | |
.Header3 { | |
font-size: x-large; | |
font-weight: bold; | |
margin: 0px; | |
line-height: 100%; | |
} | |
.Header4 { | |
font-size: large; | |
font-weight: bold; | |
margin: 0px; | |
line-height: 100%; | |
} | |
.strong_emphasis { | |
text-decoration: underline; | |
font-weight: bold; | |
} | |
.filename { | |
font-family: Arial, Helvetica, sans-serif; | |
font-size: small; | |
} | |
.underline { | |
text-decoration: underline; | |
} | |
.grn_left { | |
text-align: left; | |
color: #009900; | |
} | |
.left_topbord { | |
text-align: left; | |
border-top-style: solid; | |
border-top-width: 1px; | |
} | |
.center_topbord { | |
text-align: center; | |
border-top-style: solid; | |
border-top-width: 1px; | |
} | |
.blue_left_botbord { | |
text-align: left; | |
border-bottom-style: solid; | |
border-bottom-width: 1px; | |
color: #0000FF; | |
} | |
.blue_center_botbord { | |
text-align: center; | |
border-bottom-style: solid; | |
border-bottom-width: 1px; | |
color: #0000FF; | |
} | |
.red_center { | |
text-align: center; | |
color: #FF0000; | |
} | |
.red_left { | |
text-align: left; | |
color: #FF0000; | |
} | |
.grn_center { | |
text-align: center; | |
color: #009900; | |
} | |
.red_center_topbord { | |
text-align: center; | |
border-top-style: solid; | |
border-top-width: 1px; | |
color: #FF0000; | |
} | |
.blu_center_topbord { | |
text-align: center; | |
border-top-style: solid; | |
border-top-width: 1px; | |
color: #0000FF; | |
} | |
.indent_thick_bord { | |
border-color: #000000; | |
border-style: solid; | |
margin-left: 40px; | |
} | |
.thin_bord { | |
border-style: solid; | |
border-width: 1px; | |
} | |
.thin_bord_dbl_botbord { | |
border-left-style: solid; | |
border-left-width: 1px; | |
border-right-style: solid; | |
border-right-width: 1px; | |
border-top-style: solid; | |
border-top-width: 1px; | |
border-bottom-style: double; | |
border-bottom-width: 3px; | |
} | |
.dl_link { | |
float: right; | |
} | |
.note { | |
font-family: Arial, Helvetica, sans-serif; | |
font-weight: bold; | |
margin-left: 40px; | |
} | |
.small_note { | |
font-size: xx-small; | |
line-height: 100%; | |
} | |
.ctr { | |
text-align: center; | |
} | |
.glyph_cache { | |
font-family: "Courier New", Courier, monospace; | |
font-size: medium; | |
font-weight: normal; | |
font-style: normal; | |
margin-left: 40px; | |
background-color: #000000; | |
color: #FFFFFF; | |
} | |
.example { | |
border-style: solid; | |
border-width: 1px; | |
margin-left: 40px; | |
margin-right: 40px; | |
} | |
.rt_thick_bord { | |
border-right-style: solid; | |
border-right-color: #000000; | |
} | |
.indent { | |
margin-left: 40px; | |
} | |
.ctr_thin_bord { | |
border-style: solid; | |
border-width: 1px; | |
text-align: center; | |
} | |
.indent_thin_bord { | |
border-style: solid; | |
border-width: 1px; | |
margin-left: 40px; | |
} | |
.bold_sans { | |
font-family: Arial, Helvetica, sans-serif; | |
font-weight: bold; | |
} | |
.nowrap { | |
border-style: solid; | |
border-width: 1px; | |
white-space: nowrap; | |
font-size: small; | |
} | |
</style> | |
</head> | |
<body> | |
<table style="width: 100%; line-height: 100%;"> | |
<tr> | |
<td style="width: 484px"> | |
<table> | |
<tr> | |
<td> | |
<div style="background-position: center; background-image: url('bvlogo.png'); width: 484px; height: 400px; background-repeat: no-repeat;"> | |
<div style="position: relative; left: 0; top: 0;"> | |
<a href="http://graphics.github.com/ocd"> | |
<img src="ocdtab.png" alt="Now With OCD" style="border-width: 0; position: absolute; top: 0; right: 0;" /></a> | |
</div> | |
</div> | |
</td> | |
</tr> | |
<tr> | |
<td class="ctr"><span class="Header2">Version 2.2</span></td> | |
</tr> | |
</table> | |
</td> | |
<td> | |
<p>BLTsville is the open 2-D API designed to provide an abstract interface for both hardware and software 2-D implementations.</p> | |
<p>BLTs (BLock Transfers) involve the moving around of blocks (rectangles) of pixels. BLTsville is the place | |
to go for BLTs.</p> | |
<hr /> | |
<table style="width: 100%"> | |
<tr> | |
<td> | |
<div class="dl_link"> | |
<img alt="CC BY-ND" longdesc="Creative Commons Attribution-NoDerivs 3.0 Unported License" src="http://i.creativecommons.org/l/by-nd/3.0/88x31.png" width="88" height="31" /></div> | |
<p class="Header2">License</p> | |
</td> | |
</tr> | |
<tr> | |
<td> | |
<div> | |
<p class="small_note">The API is designed and maintained by Texas Instruments, Inc., but anyone is free | |
to use it with no cost or obligation.</p> | |
<p>This project is licensed under the <a href="http://creativecommons.org/licenses/by-nd/3.0/">Creative | |
Commons Attribution-NoDerivs 3.0 Unported License</a> (user mode), and the | |
<a href="http://www.gnu.org/licenses/gpl-2.0.html">GNU General Public License version 2</a> (kernel | |
mode).</p> | |
</div> | |
</td> | |
</tr> | |
</table> | |
<hr /> | |
<table style="width: 100%"> | |
<tr> | |
<td> | |
<p class="Header2">Dependencies</p> | |
</td> | |
</tr> | |
<tr> | |
<td> | |
<p>This project is dependent on the <a href="http://graphics.github.com/ocd">Open Color format Defintions | |
(OCD) project</a>.</p> | |
</td> | |
</tr> | |
</table> | |
<hr /> | |
<table style="width: 100%"> | |
<tr> | |
<td> | |
<p class="Header2">Source</p> | |
</td> | |
</tr> | |
<tr> | |
<td> | |
<div class="dl_link"> | |
<a href="http://github.com/graphics/bltsville/zipball/master"> | |
<img width="90" alt="download zip" src="http://github.com/images/modules/download/zip.png" /></a> | |
<a href="http://github.com/graphics/bltsville/tarball/master"> | |
<img width="90" alt="download tar" src="http://github.com/images/modules/download/tar.png" /></a> | |
</div> | |
<div> | |
Get the source code (headers) from GitHub at <a href="http://github.com/graphics/bltsville">github.com/graphics/bltsville</a>, | |
or download the project in <a href="http://github.com/graphics/bltsville/zipball/master">zip</a> or | |
<a href="http://github.com/graphics/bltsville/tarball/master">tar</a> format.</div> | |
<p>You can also clone the project with <a href="http://git-scm.com">Git</a> by running:</p> | |
<pre><a class="cmd_line">$ git clone git://github.com/graphics/bltsville</a></pre> | |
</td> | |
</tr> | |
<tr> | |
<td><hr /> | |
<table style="width: 100%"> | |
<tr> | |
<td class="Header2">Wiki</td> | |
</tr> | |
<tr> | |
<td><a href="https://github.com/graphics/bltsville/wiki">https://github.com/graphics/bltsville/wiki</a></td> | |
</tr> | |
</table> | |
</td> | |
</tr> | |
</table> | |
</td> | |
</tr> | |
</table> | |
<hr /> | |
<p class="Header1">Points of Interest in BLTsville</p> | |
<table style="width: 100%"> | |
<tr> | |
<td style="width: 50%" valign="top"> | |
<ul> | |
<li>Solid fills</li> | |
<li>Pattern fills</li> | |
<li>Copies</li> | |
<li>Color format conversion<ul> | |
<li>Extensive color format support<ul> | |
<li>RGB, BGR</li> | |
<li>RGBA, ARGB, etc.</li> | |
<li>YCbCr (YUV)<ul> | |
<li>subsampling</li> | |
<li>packed</li> | |
<li>planar</li> | |
</ul> | |
</li> | |
<li>Monochrome</li> | |
<li>Alpha-only</li> | |
<li>Look-Up Table (LUT)</li> | |
</ul> | |
</li> | |
<li>Extensible color format</li> | |
</ul> | |
</li> | |
<li>ROP4<ul> | |
<li>Three inputs</li> | |
</ul> | |
</li> | |
<li>Blends<ul> | |
<li>Pre-defined Porter-Duff blends</li> | |
<li>Pre-defined DirectFB support</li> | |
<li>Extensible blends</li> | |
</ul> | |
</li> | |
<li>Multiple </li> | |
<li>Filters<ul> | |
<li>Extensible filters</li> | |
</ul> | |
</li> | |
<li>Independent horizontal and vertical <strong>flipping</strong></li> | |
<li>Independent <strong>scaling</strong> of all three inputs</li> | |
<li>Clipping</li> | |
<li>Independent <strong>rotation</strong> of all three inputs (multiples of 90 degrees)</li> | |
</ul> | |
</td> | |
<td style="width: 50%" valign="top"> | |
<ul> | |
<li>Choice of <strong>scaling</strong> type<ul> | |
<li>Quality based choice</li> | |
<li>Speed based choice</li> | |
<li>Image type based choice</li> | |
<li>Specific scale type choice</li> | |
<li>Extensible scale type</li> | |
</ul> | |
</li> | |
<li>Synchronous operations</li> | |
<li>Asynchronous operations<ul> | |
<li>Client notification of BLT completion</li> | |
</ul> | |
</li> | |
<li>Batching<ul> | |
<li>Combine multiple BLTs into group that can be handled more efficiently by implementations<ul> | |
<li>Character BLTs</li> | |
<li>Multi-layer blending</li> | |
<li>ROP/Blend combination with specified ordering</li> | |
<li>etc.</li> | |
</ul> | |
</li> | |
<li>Delta BLTs</li> | |
</ul> | |
</li> | |
<li>Dithering<ul> | |
<li>Quality based choice</li> | |
<li>Speed based choice</li> | |
<li>Image type based choice</li> | |
<li>Specific dither type choice</li> | |
<li>Extensible dither type</li> | |
</ul> | |
</li> | |
<li>Any implementation support<ul> | |
<li>CPU</li> | |
<li>2-D Accelerator</li> | |
</ul> | |
</li> | |
</ul> | |
</td> | |
</tr> | |
</table> | |
<hr /> | |
<ul> | |
<li>BLTsville does not dictate capabilities of the implementations<ul> | |
<li>Operations specified either work or return an error indicating that the operation is not supported</li> | |
</ul> | |
</li> | |
</ul> | |
<hr /> | |
<p class="Header1">How to Get to BLTsville</p> | |
<p>BLTsville's API is defined in the BLTsville header files. A client must include <span class="inline_code">bltsville.h</span> | |
to access the implementations. This header includes the remaining headers (including <span class="inline_code">ocd.h</span>).</p> | |
<p class="note">NOTE: The <span class="underline_code">bvinternal.h</span><span class="underline"> header is for implementations | |
only</span> and should not be used by clients.</p> | |
<p>BLTsville has both user mode and a kernel mode interaces. The kernel mode interface is quite similar to (and compatible | |
with) the user mode, but due to the minor differences and license issues, there are two different sets of header files.</p> | |
<hr /> | |
<p class="Header1">History of BLTsville</p> | |
<br /> | |
<p class="Header4">Versions 1.x</p> | |
<p>BLTsville was based on a previous closed interface, which had a few implementations and shipped on a few devices. | |
That interface represented the 1.x versions. A lot was learned from that work, and these lessons were used in the | |
founding of BLTsville.</p> | |
<p class="Header4">Version 2.0</p> | |
<p>This was the initial release of the user mode interface. This version is not compatible with the 1.x versions. | |
Several minor updates were posted, but the API itself did not change, so no changes to the client or implementation were | |
required.</p> | |
<p class="Header4">Version 2.1</p> | |
<p>This is a minor update to the API, and it adds the kernel mode interface. Some additions to the API have been made. | |
Details of the changes are below with their compatibility matrices.</p> | |
<ul> | |
<li><span class="inline_code"><a href="#bv_cache">bv_cache()</a></span> was added to allow manipulation of the CPU cache. | |
This is an optional interface meant for hardware implementations.</li> | |
</ul> | |
<table class="indent_thin_bord"> | |
<tr> | |
<td class="thin_bord"> </td> | |
<td class="ctr_thin_bord"><strong>2.0 Client</strong></td> | |
<td class="ctr_thin_bord"><strong>2.0 Client</strong><br /> | |
(w/2.1 Headers)</td> | |
<td class="ctr_thin_bord"><strong>2.1 Client</strong></td> | |
</tr> | |
<tr> | |
<td class="thin_bord"><strong>2.0 Implementation</strong></td> | |
<td class="ctr_thin_bord">compatible</td> | |
<td class="ctr_thin_bord">New function and structure definitions have no effect.</td> | |
<td class="ctr_thin_bord">Client must deal with lack of <span class="inline_code"><a href="#bv_cache">bv_cache()</a></span>.</td> | |
</tr> | |
<tr> | |
<td class="thin_bord"><strong>2.0 Implementation</strong><br /> | |
(w/2.1 Headers)</td> | |
<td class="ctr_thin_bord">New function and structure definitions have no effect.</td> | |
<td class="ctr_thin_bord">New function and structure definitions have no effect.</td> | |
<td class="ctr_thin_bord">Client must deal with lack of <span class="inline_code"><a href="#bv_cache">bv_cache()</a></span>.</td> | |
</tr> | |
<tr> | |
<td class="thin_bord"><strong>2.1 Implementation</strong></td> | |
<td class="ctr_thin_bord">New function and structures have no effect.</td> | |
<td class="ctr_thin_bord">New function and structures have no effect.</td> | |
<td class="ctr_thin_bord">compatible</td> | |
</tr> | |
</table> | |
<ul> | |
<li><span class="inline_code"><a href="#bvbuffdesc">bvbuffdesc</a></span> was extended with the | |
<span class="inline_code"><a href="#bvbuffdesc.auxtype">auxtype</a></span> and <span class="inline_code"> | |
<a href="#bvbuffdesc.auxptr">auxptr</a></span> members to allow buffer descriptions beyond a virtual address. | |
Note that only the kernel mode interface currently includes a standard <span class="inline_code">auxtype</span>, but | |
user mode interface <span class="inline_code">auxtype</span>s may be added later. Both interfaces provide a mechanism | |
for individual vendors to add their own <span class="inline_code">auxtype</span>, using the same vendor ID mechanism | |
as the rest of BLTsville.</li> | |
</ul> | |
<table class="indent_thin_bord"> | |
<tr> | |
<td class="thin_bord"> </td> | |
<td class="ctr_thin_bord"><strong>2.0 Client</strong></td> | |
<td class="ctr_thin_bord"><strong>2.0 Client</strong><br /> | |
(w/2.1 Headers)</td> | |
<td class="ctr_thin_bord"><strong>2.1 Client</strong></td> | |
</tr> | |
<tr> | |
<td class="thin_bord"><strong>2.0 Implementation</strong></td> | |
<td class="ctr_thin_bord">compatible</td> | |
<td class="ctr_thin_bord">Client must clear <span class="inline_code"><a href="#bvbuffdesc">bvbuffdesc</a></span> | |
using <span class="inline_code"><span style="white-space: nowrap">sizeof(<a href="#bvbuffdesc">bvbuffdesc</a>)</span></span>.</td> | |
<td class="ctr_thin_bord">Implementation must handle <span class="inline_code"> | |
<a href="#bvbuffdesc.structsize">bvbuffdesc.structsize</a> > <span style="white-space: nowrap">sizeof(<a href="#bvbuffdesc">bvbuffdesc</a>)</span></span>.</td> | |
</tr> | |
<tr> | |
<td class="thin_bord"><strong>2.0 Implementation</strong><br /> | |
(w/2.1 Headers)</td> | |
<td class="ctr_thin_bord">Implementation must handle <span class="inline_code"> | |
<a href="#bvbuffdesc.structsize">bvbuffdesc.structsize</a> < <span style="white-space: nowrap">sizeof(<a href="#bvbuffdesc">bvbuffdesc</a>)</span></span>.</td> | |
<td class="ctr_thin_bord">Client must clear <span class="inline_code"><a href="#bvbuffdesc">bvbuffdesc</a></span> | |
using <span class="inline_code"><span style="white-space: nowrap">sizeof(<a href="#bvbuffdesc">bvbuffdesc</a>)</span></span>.</td> | |
<td class="ctr_thin_bord">Client must deal with implementation that uses <span class="inline_code"> | |
<a href="#bvbuffdesc.virtaddr">bvbuffdesc.virtaddr</a></span> or returns error if <span class="inline_code"> | |
<a href="#bvbuffdesc.virtaddr">bvbuffdesc.virtaddr</a></span> is 0.</td> | |
</tr> | |
<tr> | |
<td class="thin_bord"><strong>2.1 Implementation</strong></td> | |
<td class="ctr_thin_bord">Implementation must handle <span class="inline_code"> | |
<a href="#bvbuffdesc.structsize">bvbuffdesc.structsize</a> < <span style="white-space: nowrap">sizeof(<a href="#bvbuffdesc">bvbuffdesc</a>)</span></span>.</td> | |
<td class="ctr_thin_bord">Client must clear <span class="inline_code"><a href="#bvbuffdesc">bvbuffdesc</a></span> | |
using <span class="inline_code"><span style="white-space: nowrap">sizeof(<a href="#bvbuffdesc">bvbuffdesc</a>)</span></span>.</td> | |
<td class="ctr_thin_bord">compatible</td> | |
</tr> | |
</table> | |
<ul> | |
<li>Added documentation of <a href="#NOP">NOP BLT</a> used as synchronization mechanism for <a href="#BVFLAG_ASYNC"> | |
asynchronous BLTs</a>.<ul> | |
<li>Clients that do not use <a href="#BVFLAG_ASYNC">asynchronous BLTs</a> or the <a href="#NOP">NOP BLT</a> will | |
not be affected.</li> | |
<li>Implementations that do not support the NOP BLT will return an error. This will not cause a problem | |
for clients when using implementations which are actually synchronous. For clients using asynchronous | |
implementations, an alternate supported but innocuous BLT will be necessary (e.g. copying a pixel to itself).</li> | |
</ul> | |
</li> | |
</ul> | |
<p class="Header4">Version 2.2</p> | |
<p>This is a minor update which includes the following:</p> | |
<ul> | |
<li>Addition of the <span class="inline_code"><a href="#src2auxdstrect">src2auxdstrect</a></span> and | |
<span class="inline_code"><a href="#maskauxdstrect">maskauxdstrect</a></span> members to <span class="inline_code"> | |
<a href="#bvbltparams">bvbltparams</a></span> with example.</li> | |
<li>Addition of <span class="inline_code"><a href="#BVFLAG_SRC2_AUXDSTRECT">BVFLAG_SRC2_AUXDSTRECT</a></span> and <span class="inline_code"> | |
<a href="#BVFLAG_MASK_AUXDSTRECT">BVFLAG_MASK_AUXDSTRECT</a></span> flags.</li> | |
<li>Added <span class="inline_code"><a href="#BVAT_PHYSADDR">BVAT_PHYSADDR</a></span> to the kernel mode | |
<span class="inline_code"><a href="#bvbuffdesc.auxtype">bvbuffdesc.auxtype</a></span> enumerations.</li> | |
<li>Added clarification to the <span class="inline_code"><a href="#bvphysdesc">bvphysdesc</a></span> documentation.</li> | |
</ul> | |
<p>Compatibility</p> | |
<ul> | |
<li>Clients that do not use the <span class="inline_code"><a href="#BVFLAG_SRC1_AUXDSTRECT">BVFLAG_*_AUXDSTRECT</a></span> | |
flags will not be affected.</li> | |
<li>Clients using the new (long) <span class="inline_code"><a href="#bvbltparams">bvbltparams</a></span> will work with | |
older implementations. If the clients set the <span class="inline_code"><a href="#BVFLAG_SRC2_AUXDSTRECT"> | |
BVFLAG_*_AUXDSTRECT</a></span> flags, the implementations will return <span class="inline_code">BVERR_FLAGS</span>, | |
indicating the lack of support for this feature.</li> | |
<li>Implementations supporting the new <span class="inline_code"><a href="#bvbltparams">bvbltparams</a></span> will | |
accept the older (smaller) version, distinguished by the <span class="inline_code"> | |
<a href="#bvbltparams.structsize">structsize</a></span> member. Clients using the older versions will not set | |
the <span class="inline_code"><a href="#BVFLAG_SRC2_AUXDSTRECT">BVFLAG_*_AUXDSTRECT</a></span> flags, so the new | |
members will not be utilized.</li> | |
<li>Clients using <span class="inline_code"><a href="#BVAT_PHYSADDR">BVAT_PHYSADDR</a></span> will get an error from | |
implementations that do not support this enumeration. The <span class="inline_code"><a href="#BVAT_PHYSDESC"> | |
BVAT_PHYSDESC</a></span> may be used if supported by the implementation, but care must be taken to ensure the buffer | |
is defined properly. See <span class="inline_code"><a href="#bvphysdesc">bvphysdesc</a></span> for details.</li> | |
</ul> | |
<hr /> | |
<p class="Header1">BLTsville Neighborhoods</p> | |
<p>Implementations may be software (CPU) or 2-D hardware, and many may coexist. Each implementation will have an individual | |
entry point, so it can be directly addressed. But there will also be a more general interface for each of these two | |
types of implementations so that system integrators can choose the most appropriate implementation. In other words, | |
the system integrator will choose one software and one 2-D hardware implementation to be the "default" used when a client | |
does not need to choose a specific implementation.</p> | |
<p class="Header2">User Mode Interface</p> | |
<p>Clients use the standard names below to access the default implementations. The client then imports the pointers | |
to the functions. (The specific name decoration and import method will be dictated by the host Operating System (O/S).) | |
Some examples:</p> | |
<ul> | |
<li>CPU: <span class="filename">bltsville_cpu</span><ul> | |
<li>Linux/Android: <span class="filename">libbltsville_cpu.so</span></li> | |
<li>Windows: <span class="filename">bltsville_cpu.dll</span></li> | |
<li>etc.</li> | |
</ul> | |
</li> | |
<li>2-D hardware: <span class="filename">bltsville_hw2d</span><ul> | |
<li>Linux/Android: <span class="filename">libbltsville_hw2d.so</span></li> | |
<li>Windows: <span class="filename">bltsville_hw2d.dll</span></li> | |
<li>etc.</li> | |
</ul> | |
</li> | |
</ul> | |
<p>Usually these entry points will be symbolic links (either explicit in systems like Linux which support them, or implicit | |
using a thin wrapper) to the specific implementation. This allows system integrators to connect the client with the | |
most capable implementation available in the system. For example, <span class="filename">bltsville_hw2d</span> might | |
be a symbolic link to <span class="filename">bltsville_gc2d</span>.</p> | |
<p>In addition, there may be more implementations co-existing in a given system. These will have additional unique | |
names as determined by the vendors. For example:</p> | |
<ul> | |
<li>Reference CPU software implementation: <span class="filename">bltsville_refcpu</span></li> | |
<li>System DMA 2-D hardware implementation: <span class="filename">bltsville_mydma</span></li> | |
</ul> | |
<p class="Header3">Initialization</p> | |
<p>In general, each O/S has the ability to manually load a library. This in turn causes a function in the library | |
to be called so the library can perform initialization. Unfortunately, not all O/Ss allow this initialization | |
function to return an error if the initialization fails. Equally unfortunately, it may be necessary for the | |
initialization to be performed in that function. To accommodate this, BLTsville defers the specific initialization | |
to the O/S environment.</p> | |
<p class="Header4">Linux/Android</p> | |
<p>The client will call <span class="inline_code">dlopen()</span> to open the library. It will then import the | |
<span class="inline_code">bv_*()</span> functions, and call them as desired. Initialization will occur in | |
association with one or more of these activities. If the initialization fails, the bv_*() functions will return | |
the <span class="inline_code">BVERR_RSRC</span> error, indicating that a required resource was not obtained.</p> | |
<p class="imponly"><strong>Implementations Only<br /> | |
</strong><br /> | |
If the library has designated a function with the <span class="inline_code">__attribute__ ((constructor))</span>, that | |
function will be called. Linux implementations may use this function to perform initialization (including opening | |
an interface to an associated kernel module). However, since this function cannot return an error, and thus cannot | |
fail, if the initialization fails, this must be recorded. Then, when the client calls any of the | |
<span class="inline_code">bv_*()</span> functions, these should immediately return the <span class="inline_code"> | |
BVERR_RSRC</span> error, indicating that the library was unable to initialize (obtain a necessary resource).<br /> | |
<br /> | |
Linux implementations may also choose to initialize on the first call to a <span class="inline_code">bv_*()</span> | |
function. Failure is likewise indicated by returning the <span class="inline_code">BVERR_RSRC</span> error.<br /> | |
<br /> | |
<strong>NOTE: Be careful not to repeatedly attempt initialization when a failure is encountered. Some | |
initializations, and especially initialization failures, can take a long time. This means clients trying to call | |
</strong><span class="inline_code"><strong>bv_*()</strong></span><strong> functions (presumably before falling back to | |
alternatives) will be repeatedly penalized if the library can't initialize. Instead, attempt initialization | |
once, and from them on return <span class="inline_code">BVERR_RSRC</span>.</strong></p> | |
<p class="Header2">Kernel Mode Interface</p> | |
<p>For most kernel space BLTsville clients, only a 2-D hardware implementation will be used. However, both types of | |
implementations are supported. Clients use the standard names below to access the default implementations and obtain | |
pointers to the functions. (The specific method of obtaining the interface will be dictated by the host Operating | |
System (O/S).) Some examples:</p> | |
<ul> | |
<li>CPU<ul> | |
<li>Linux/Android <span class="inline_code">bvcpu_entry()</span></li> | |
<li>etc.</li> | |
</ul> | |
</li> | |
<li>2-D hardware<ul> | |
<li>Linux/Android <span class="inline_code">bv2d_entry()</span></li> | |
<li>etc.</li> | |
</ul> | |
</li> | |
</ul> | |
<p>These entry points may represent the implementations themselves, but more likely they will link the client to the implementations | |
using more specific names. For example, <span class="inline_code">bv2d_entry()</span> may link the client to | |
<span class="inline_code">gcbv_entry()</span>.</p> | |
<p>In addition, there may be more implementations co-existing in the kernel. These will require additional unique | |
names as determined by the vendors. For example:</p> | |
<ul> | |
<li>Reference CPU software implementation: <span class="inline_code">cpurefbv_entry()</span></li> | |
<li>Vivante GC320 2-D hardware implementation: <span class="inline_code">gcbv_entry()</span></li> | |
</ul> | |
<hr /> | |
<p class="Header1">Things To Do In BLTsville</p> | |
<p>BLTsville's interface consists of three or four functions per implementation, which must be imported by the | |
client at run time:</p> | |
<ul> | |
<li><span class="inline_code"><a href="#bv_map">bv_map()</a></span></li> | |
<li><span class="inline_code"><a href="#bv_blt">bv_blt()</a></span></li> | |
<li><span class="inline_code"><a href="#bv_unmap">bv_unmap()</a></span></li> | |
<li><span class="inline_code"><a href="#bv_cache">bv_cache()</a></span> (optional)</li> | |
</ul> | |
<p class="note">NOTE: If the library failed to initialize, these functions will return <span class="inline_code"> | |
BVERR_RSRC</span>, indicating that a required resource was not obtained.</p> | |
<a name="bv_map" class="Code_Header">bv_map()</a> | |
<p class="code_block">enum bverror bv_map(<a href="#bvbuffdesc">struct bvbuffdesc* buffdesc</a>);</p> | |
<p><span class="strong_emphasis">BLTsville does not allocate buffers.</span> Clients must describe a buffer | |
in BLTsville using the <span class="inline_code"><a href="#bvbuffdesc">bvbuffdesc</a></span> structure so a given implementation | |
can access the buffer.</p> | |
<p><span class="inline_code">bv_map()</span> is used to provide the implementation an opportunity to associate hardware | |
resources with the specified buffer. Most hardware requires this type of mapping, and there is usually appreciable | |
overhead associated with it. By providing a separate call for this operation, BLTsville allows the client to move | |
this overhead to the most appropriate time in its execution.</p> | |
<p>For a given buffer, the client can call the <span class="inline_code">bv_map()</span> function imported from each implementation | |
to establish the mapping immediately. But this is not required.</p> | |
<p>As a special bonus, BLTsville clients can call to any implementation's <span class="inline_code">bv_map()</span>. | |
This is sufficient to indicate that the client can be trusted to make the corresponding call to | |
<span class="inline_code"><a href="#bv_unmap">bv_unmap()</a></span> upon destruction of the buffer. Then when a client | |
calls an implementation's <span class="inline_code"><a href="#bv_blt">bv_blt()</a></span>, if the mapping needs to be done, | |
it's done at that time. But the mapping is maintained, so that the overhead is avoided on subsequent | |
<span class="inline_code"><a href="#bv_blt">bv_blt()</a></span> calls. This lets implementations use <em>lazy mapping</em> | |
only as necessary. If an implementation is not called, the mapping is not done.</p> | |
<p><em>Normally, the lowest overhead </em><span class="inline_code"><em>bv_map()</em></span><em> call will be in the CPU-based | |
implementation. So most clients will want to make a single, low overhead </em><span class="inline_code"><em>bv_map()</em></span><em> | |
call to the bltsville_cpu implementation to avoid the mapping/unmapping overhead on each </em><span class="inline_code"> | |
<a href="#bv_blt"><em>bv_blt()</em></a></span><em> call, while avoiding the mapping overhead when possible.</em></p> | |
<p><em><strong>Calling </strong></em><span class="inline_code"><em><strong>bv_map()</strong></em></span><em><strong> is | |
actually optional prior to calling </strong></em><span class="inline_code"><a href="#bv_blt"><em><strong>bv_blt()</strong></em></a></span><em><strong>. | |
However, if it is not called at least once for a given buffer, it must be assumed that </strong></em> | |
<span class="inline_code"><a href="#bv_unmap"><strong><em>bv_unmap()</em></strong></a></span><em><strong> will not be called. | |
So the mapping must be done when </strong></em><span class="inline_code"><a href="#bv_blt"><em><strong>bv_blt()</strong></em></a></span><em><strong> | |
is called, and unmapping done when it is complete. This means the overhead will be incurred for every </strong> | |
</em><a href="#bv_blt" class="inline_code"><em><strong>bv_blt()</strong></em></a><em><strong> call which uses that buffer.</strong></em></p> | |
<p class="note">NOTE: Obviously any API cannot add capabilities beyond an implementation's capabilities. So, for example, | |
if an implementation requires memory to be allocated from a special pool of memory, that responsibility falls upon the client. | |
The <span class="inline_code">bv_map()</span> function for that implementation will need to check the characteristics of | |
the memory and return an error if it does not meet the necessary criteria.</p> | |
<p class="Header4"><a name="bv_map_Function_Sequences">Function Sequences</a></p> | |
<p>To clarify, here are some function sequences and the operations associated with them:</p> | |
<table class="indent"> | |
<tr> | |
<td class="ctr_thin_bord"><strong>Implementation</strong></td> | |
<td class="ctr_thin_bord"><strong>Function</strong></td> | |
<td class="ctr_thin_bord"><strong>Operation</strong></td> | |
</tr> | |
<tr> | |
<td class="ctr_thin_bord">A</td> | |
<td class="thin_bord"><span class="inline_code"><a href="#bv_blt">bv_blt()</a></span></td> | |
<td class="thin_bord">map A<br /> | |
BLT A<br /> | |
unmap A</td> | |
</tr> | |
<tr> | |
<td class="ctr_thin_bord">A</td> | |
<td class="thin_bord"><span class="inline_code"><a href="#bv_blt">bv_blt()</a></span></td> | |
<td class="thin_bord">map A<br /> | |
BLT A<br /> | |
unmap A</td> | |
</tr> | |
<tr> | |
<td class="ctr_thin_bord">B</td> | |
<td class="thin_bord"><span class="inline_code"><a href="#bv_blt">bv_blt()</a></span></td> | |
<td class="thin_bord">map B<br /> | |
BLT B<br /> | |
unmap B</td> | |
</tr> | |
</table> | |
<br /> | |
<table class="indent"> | |
<tr> | |
<td class="ctr_thin_bord"><strong>Implementation</strong></td> | |
<td class="ctr_thin_bord"><strong>Function</strong></td> | |
<td class="ctr_thin_bord"><strong>Operation</strong></td> | |
</tr> | |
<tr> | |
<td class="ctr_thin_bord">A</td> | |
<td class="thin_bord"><span class="inline_code"><a href="#bv_map">bv_map()</a></span></td> | |
<td class="thin_bord">map A</td> | |
</tr> | |
<tr> | |
<td class="ctr_thin_bord">A</td> | |
<td class="thin_bord"><span class="inline_code"><a href="#bv_blt">bv_blt()</a></span></td> | |
<td class="thin_bord">BLT A</td> | |
</tr> | |
<tr> | |
<td class="ctr_thin_bord">A</td> | |
<td class="thin_bord"><span class="inline_code"><a href="#bv_blt">bv_blt()</a></span></td> | |
<td class="thin_bord">BLT A</td> | |
</tr> | |
<tr> | |
<td class="ctr_thin_bord">A</td> | |
<td class="thin_bord"><span class="inline_code"><a href="#bv_unmap">bv_unmap()</a></span></td> | |
<td class="thin_bord">unmap A</td> | |
</tr> | |
</table> | |
<br /> | |
<table class="indent"> | |
<tr> | |
<td class="ctr_thin_bord"><strong>Implementation</strong></td> | |
<td class="ctr_thin_bord"><strong>Function</strong></td> | |
<td class="ctr_thin_bord"><strong>Operation</strong></td> | |
</tr> | |
<tr> | |
<td class="ctr_thin_bord">A</td> | |
<td class="thin_bord"><span class="inline_code"><a href="#bv_map">bv_map()</a></span></td> | |
<td class="thin_bord">map A</td> | |
</tr> | |
<tr> | |
<td class="ctr_thin_bord">B</td> | |
<td class="thin_bord"><span class="inline_code"><a href="#bv_map">bv_map()</a></span></td> | |
<td class="thin_bord">map B</td> | |
</tr> | |
<tr> | |
<td class="ctr_thin_bord">A</td> | |
<td class="thin_bord"><span class="inline_code"><a href="#bv_blt">bv_blt()</a></span></td> | |
<td class="thin_bord">BLT A</td> | |
</tr> | |
<tr> | |
<td class="ctr_thin_bord">B</td> | |
<td class="thin_bord"><span class="inline_code"><a href="#bv_blt">bv_blt()</a></span></td> | |
<td class="thin_bord">BLT B</td> | |
</tr> | |
<tr> | |
<td class="ctr_thin_bord">A</td> | |
<td class="thin_bord"><span class="inline_code"><a href="#bv_unmap">bv_unmap()</a></span></td> | |
<td class="thin_bord">unmap A</td> | |
</tr> | |
<tr> | |
<td class="ctr_thin_bord">B</td> | |
<td class="thin_bord"><span class="inline_code"><a href="#bv_unmap">bv_unmap()</a></span></td> | |
<td class="thin_bord">unmap B</td> | |
</tr> | |
</table> | |
<br /> | |
<table class="indent"> | |
<tr> | |
<td class="ctr_thin_bord"><strong>Implementation</strong></td> | |
<td class="ctr_thin_bord"><strong>Function</strong></td> | |
<td class="ctr_thin_bord"><strong>Operation</strong></td> | |
</tr> | |
<tr> | |
<td class="ctr_thin_bord">A</td> | |
<td class="thin_bord"><span class="inline_code"><a href="#bv_map">bv_map()</a></span></td> | |
<td class="thin_bord">map A</td> | |
</tr> | |
<tr> | |
<td class="ctr_thin_bord">B</td> | |
<td class="thin_bord"><span class="inline_code"><a href="#bv_blt">bv_blt()</a></span></td> | |
<td class="thin_bord">map B<br /> | |
BLT B</td> | |
</tr> | |
<tr> | |
<td class="ctr_thin_bord">B</td> | |
<td class="thin_bord"><span class="inline_code"><a href="#bv_blt">bv_blt()</a></span></td> | |
<td class="thin_bord">BLT B</td> | |
</tr> | |
<tr> | |
<td class="ctr_thin_bord">A</td> | |
<td class="thin_bord"><span class="inline_code"><a href="#bv_unmap">bv_unmap()</a></span></td> | |
<td class="thin_bord">unmap A<br /> | |
unmap B</td> | |
</tr> | |
</table> | |
<br /> | |
<div class="note"> | |
NOTE: Calling <span class="inline_code">bv_map()</span> and <span class="inline_code"><a href="#bv_unmap"> | |
bv_unmap()</a></span> with the same <span class="inline_code"><a href="#bvbuffdesc">bvbuffdesc</a></span> from | |
different, unsynchronized threads, even (especially) from different implementations, will result in undefined | |
behavior. This is similar to calling <span class="inline_code">malloc()</span> and <span class="inline_code"> | |
free()</span> using the same buffer pointer in different, unsynchronized threads. While this may work | |
sometimes and for some implementations and combinations of implementations, BLTsville does not provide any | |
synchronization mechanism to make this safe. Clients must ensure that these calls are synchronized in cases | |
where such behavior appears to be necessary.</div> | |
<br /> | |
<a name="bv_blt" class="Code_Header">bv_blt()</a> | |
<p class="code_block">enum bverror bv_blt(<a href="#bvbltparams">struct bvbltparams* bltparams</a>);</p> | |
<p>The main function of BLTsville is <span class="inline_code">bv_blt()</span>. A <span class="inline_code"> | |
<a href="#bvbltparams">bvbltparams</a></span> structure is passed into <span class="inline_code">bv_blt()</span> to trigger | |
the desired 2-D operation.</p> | |
<a name="bv_unmap" class="Code_Header">bv_unmap()</a> | |
<p class="code_block">enum bverror bv_unmap(<a href="#bvbuffdesc">struct bvbuffdesc* buffdesc</a>);</p> | |
<p><span class="inline_code">bv_unmap()</span> is used to free implementation resources associated with a buffer. | |
Normally, if <span class="inline_code"><a href="#bv_map">bv_map()</a></span> was called for a given buffer, | |
<span class="inline_code">bv_unmap()</span> should be called as well.</p> | |
<p>For convenience, only one <span class="inline_code">bv_unmap()</span> needs to be called for each buffer, regardless | |
of how many implementations were used, including multiple calls to <span class="inline_code"><a href="#bv_map">bv_map()</a></span>.</p> | |
<p>Also for convenience, <span class="inline_code">bv_unmap()</span> may be called multiple times on the same buffer. | |
Note that only the first call will actually free (all) the associated resources. See the | |
<a href="#bv_map_Function_Sequences">Function Sequences</a> under <span class="inline_code"><a href="#bv_map">bv_map()</a></span> | |
for more details.</p> | |
<p class="imponly"><strong>Implementations Only</strong><br /> | |
<br /> | |
Implementations must ensure that unmapping of buffers which are in use by asynchronous BLTs are appropriately delayed to | |
avoid improper access.</p> | |
<a name="bv_cache" class="Code_Header">bv_cache()</a> | |
<p class="code_block">enum bverror bv_cache(<a href="#bvcopprams">struct bvcopparams *copparams</a>);</p> | |
<p><span class="inline_code">bv_cache()</span> provides manual CPU cache control to maintain cache coherence of surfaces | |
between the CPU and other hardware. The <a href="#bvbuffdesc">bvcopparams</a> structure provides the information needed | |
to properly manipulate the CPU cache.</p> | |
<p>This function is <em>optional</em>. If this function fails to import, it means the implementation does not provide | |
it, but <span class="inline_code"><a href="#bv_map">bv_map()</a></span>, <span class="inline_code"> | |
<a href="#bv_blt">bv_blt()</a></span>, and <span class="inline_code"><a href="#bv_unmap">bv_unmap()</a></span> may still | |
be used.</p> | |
<p><em>In general, this function will be provided with BLTsville implementations which utilize 2-D hardware, even though | |
it manipulates the CPU cache. This is because most systems require a kernel module to manipulate the cache, and this | |
is not always practical to include with a user-mode CPU implementation.</em></p> | |
<p><strong>BEWARE: Manipulation of the CPU cache is tricky. Moreover, different CPUs behave differently, so | |
cache manipulation that works on one device may fail on another. Also, mismanaged operation of the cache can have | |
significant impact on overall system performance. And incorrect manipulation of the cache can cause instability or | |
crashes. Please read and understand all of the discussions below before using this function.</strong></p> | |
<ol> | |
<li>To avoid system instability, do not perform cache operations on buffers which would not be accessed by BLTsville.</li> | |
<li>For maximum performance, combine adjacent rectangles into one <span class="inline_code">bv_cache()</span> call. | |
For example, when BLTing a line of characters, do not issue a <span class="inline_code">bv_cache()</span> call for each | |
character. Instead, make one call to bv_cache() which includes all the characters.</li> | |
<li>When using a hardware BLTsville implementation to read data written into a cached surface by the CPU, use the | |
<span class="inline_code"><a href="#CPU_TO_DEVICE">BVCACHE_CPU_TO_DEVICE</a></span> operation after the CPU has completed | |
its operation and before the hardware BLTsville operation is initiated.</li> | |
<li>When using a hardware BLTsville implementation to write data into a cached surface that will be read by the CPU, | |
use the <span class="inline_code"><a href="#CPU_FROM_DEVICE">BVCACHE_CPU_FROM_DEVICE</a></span> operation after the | |
hardware BLTsville operation has completed (note this means after the callback if the BLT is asynchronous) and before | |
the CPU accesses the surface.</li> | |
<li>When using a hardware BLTsville implementation to write data into a cached surface that has been written by the | |
CPU, using the <span class="inline_code"><a href="#CPU_TO_DEVICE">BVCACHE_CPU_TO_DEVICE</a></span> operation after the | |
CPU has completed its operation and before the hardware BLTsville operation is initiated.<ul> | |
<li class="bold_sans">NOTE: This cache operation may not be necessary on all hardware, but it is good practice to perform it | |
anyway. This operation will be necessary for a CPU with a write allocation policy on the cache, but may not | |
be necessary for CPUs without such a configuration.</li> | |
<li class="bold_sans"><strong>NOTE WELL: CPU access to a destination buffer is not always initiated by the client. Buffers | |
recently allocated may be cleared by the CPU on behalf of the client via the allocation call. Failure to perform | |
this operation may result in image corruption even if no further CPU accesses are performed on the surface!</strong></li> | |
</ul> | |
</li> | |
</ol> | |
<table class="example"> | |
<tr> | |
<td> | |
<p><strong>Example</strong>: On one particular device, a surface was allocated using the standard user mode | |
<span class="inline_code">malloc()</span>. An image was copied into a portion of this surface using a hardware | |
implementation of BLTsville. The result was then read by the CPU.</p> | |
<p>Logically, <span class="inline_code">bv_cache()</span> was used to perform a <span class="inline_code"> | |
<a href="#CPU_FROM_DEVICE">BVCACHE_CPU_FROM_DEVICE</a></span> operation after the hardware-based BLTsville operation | |
completed, but before the CPU read was performed. However, corruption appeared both inside the image copied, | |
as well as outside the image!</p> | |
<p>Both corruptions were caused by not realizing that there was a CPU operation (clear) performed on behalf of the | |
<span class="inline_code">malloc()</span>, for which the proper cache manipulation was not performed.</p> | |
<p>The corruption outside the image was due to data in the cache being invalidated before it reached the memory. | |
As mentioned above, buffers allocated are normally cleared by the system. In this case, since the buffer used | |
for the surface was configured with a write allocated cache, this meant that not all writes to clear the buffer | |
were in memory when the <span class="inline_code"><a href="#CPU_FROM_DEVICE">BVCACHE_CPU_FROM_DEVICE</a></span> | |
operation was performed. As a result, the uncommitted data in the cache was invalidated and lost, and the | |
previous contents of the memory remained for the CPU to read.</p> | |
<p>The corruption inside the image was caused by data in the cache being committed to memory after the hardware | |
BLT completed, but before the <span class="inline_code"><a href="#CPU_FROM_DEVICE">BVCACHE_CPU_FROM_DEVICE</a></span> | |
operation was executed.</p> | |
<p>Both corruptions were corrected by performing a <span class="inline_code"><a href="#CPU_TO_DEVICE">BVCACHE_CPU_TO_DEVICE</a></span> | |
operation on the <span class="underline">destination</span> surface <strong>before</strong> performing the BLT (item | |
5 above), in addition to the <span class="inline_code"><a href="#CPU_FROM_DEVICE">BVCACHE_CPU_FROM_DEVICE</a></span> | |
operation performed <strong>after</strong> the BLT (item 3 above).</p> | |
</td> | |
</tr> | |
</table> | |
<br /> | |
<hr /><a name="bvbltparams" class="Code_Header">bvbltparams</a> | |
<p><span class="inline_code">bvbltparams</span> is the central structure in BLTsville. This structure holds the details | |
of the BLT being requested by the client.</p> | |
<p class="small_code_block">union bvop {<br /> | |
unsigned short <a href="#rop">rop</a>;<br /> | |
enum bvblend <a href="#blend">blend</a>;<br /> | |
struct bvfilter *<a href="#filter">filter</a>;<br /> | |
};<br /> | |
<br /> | |
struct bvinbuff {<br /> | |
<a href="#bvbuffdesc">struct bvbuffdesc</a> *<a href="#src1.desc">desc</a>;<br /> | |
<a href="#bvtileparams">struct bvtileparams</a> *<a href="#src1.tileparams">tileparams</a>;<br /> | |
};<br /> | |
<br /> | |
struct bvbltparams {<br /> | |
unsigned int <a href="#bvbltparams.structsize">structsize</a>;<br /> | |
<br /> | |
char *<a href="#errdesc">errdesc</a>;<br /> | |
<br /> | |
unsigned long <a href="#implementation">implementation</a>;<br /> | |
unsigned long <a href="#flags">flags</a>;<br /> | |
union bvop <a href="#op">op</a>;<br /> | |
<br /> | |
void *<a href="#colorkey">colorkey</a>;<br /> | |
union bvalpha <a href="#globalalpha">globalalpha</a>;<br /> | |
<br /> | |
enum bvscalemode <a href="#scalemode">scalemode</a>;<br /> | |
enum bvdithermode <a href="#dithermode">dithermode</a>;<br /> | |
<br /> | |
<a href="#bvbuffdesc">struct bvbuffdesc</a> *<a href="#dstdesc">dstdesc</a>;<br /> | |
<a href="#bvsurfgeom">struct bvsurfgeom</a> *<a href="#dstgeom">dstgeom</a>;<br /> | |
<a href="#bvrect">struct bvrect</a> <a href="#dstrect">dstrect</a>;<br /> | |
<br /> | |
union bvinbuff <a href="#src1">src1</a>;<br /> | |
<a href="#bvsurfgeom">struct bvsurfgeom</a> *<a href="#src1geom">src1geom</a>;<br /> | |
<a href="#bvrect">struct bvrect</a> <a href="#src1rect">src1rect</a>;<br /> | |
<br /> | |
union bvinbuff <a href="#src2">src2</a>;<br /> | |
<a href="#bvsurfgeom">struct bvsurfgeom</a> *<a href="#src2geom">src2geom</a>;<br /> | |
<a href="#bvrect">struct bvrect</a> <a href="#src2rect">src2rect</a>;<br /> | |
<br /> | |
union bvinbuff <a href="#mask">mask</a>;<br /> | |
<a href="#bvsurfgeom">struct bvsurfgeom</a> *<a href="#maskgeom">maskgeom</a>;<br /> | |
<a href="#bvrect">struct bvrect</a> <a href="#maskrect">maskrect</a>;<br /> | |
<br /> | |
<a href="#bvrect">struct bvrect</a> <a href="#cliprect">cliprect</a>;<br /> | |
<br /> | |
unsigned long <a href="#batchflags">batchflags</a>;<br /> | |
struct bvbatch *<a href="#batch">batch</a>;<br /> | |
<br /> | |
void (*<a href="#callbackfn">callbackfn</a>)(<a href="#bvcallbackerror">struct | |
bvcallbackerror</a> *err,<br /> | |
| |
unsigned long callbackdata);<br /> | |
unsigned long <a href="#callbackdata">callbackdata</a>;<br /> | |
<br /> | |
<a href="#bvrect">struct bvrect</a> <a href="#src2auxdstrect">src2auxdstrect</a>;<br /> | |
<a href="#bvrect">struct bvrect</a> <a href="#maskauxdstrect">maskauxdstrect</a>;<br /> | |
};</p> | |
<a name="bvbltparams.structsize" class="Code_Header_2">bvbltparams.structsize</a> | |
<p><span class="code_block">unsigned long structsize; /* input */</span></p> | |
<p>This member is used to allow backwards and forwards compatibility between versions of BLTsville. It should be set | |
to the <span class="inline_code">sizeof()</span> the structure by the client or implementation, whichever allocated the | |
structure.</p> | |
<p>BLTsville is designed to be forwards and backwards compatible between client and library versions. But this compatibility | |
would be eliminated if clients chose to check for a specific version of the BLTsville implementations and fail if the specific | |
version requested was not in place. So, instead of exporting a version number, BLTsville structures use the | |
<span class="inline_code">structsize</span> member to indicate the number of bytes in the structure. This is used | |
to communicate between the client and implementation which portions of the structure exist. This effectively bypasses | |
the concept of a version and focuses on the specifics of what changes need to be considered to maintain compatibility.</p> | |
<ol> | |
<li>When an old client calls into a new implementation, that implementation will realize if the client only provides | |
a subset of an updated structure. The implementation will handle this and utilize only that information which | |
has been provided. New features will be disabled, but functionality will be maintained.</li> | |
<li>When a new client calls into an old implementation, that implementation will ignore the extra members of the structure | |
and operate in ignorance of them. If these members are necessary for some new functionality, this will be evident | |
from other fields in the structure, so that the implementation can gracefully fail.</li> | |
</ol> | |
<p>If <span class="inline_code">structsize</span> is set to a value that is too small for an implementation, it may return | |
a <span class="inline_code"><a href="#BVERR_BLTPARAMS_VERS">BVERR_BLTPARAMS_VERS</a></span> error.</p> | |
<p class="Code_Header_2"><a name="bvbltparams.errdesc">bvbltparams.errdesc</a></p> | |
<p><span class="code_block">char* errdesc; /* output */</span></p> | |
<p><span class="inline_code">errdesc</span> is optionally used by implementations to pass a 0-terminated string with additional | |
debugging information back to clients for debugging purposes. <span class="inline_code">errdesc</span> is not localized | |
or otherwise meant to provide information that is displayed to users.</p> | |
<p class="Code_Header_2"><a name="implementation">bvbltparams.implementation</a></p> | |
<p class="code_block">unsigned long implementation; /* input */</p> | |
<p>Multiple implementations of BLTsville can be combined under managers which can distribute the BLT requests to the implementations | |
based on whatever criteria the manager chooses. This might include availability of the operation, performance, loading, | |
or power state. In such a scenario, the client may need to override or augment the choice made by the manager. | |
This field allows that control.</p> | |
<p><strong><em>Note that this feature is extremely complicated, and more detailed documentation needs to be created to allow | |
creation of managers and smooth integration by a client. There are serious issues that must be understood before any | |
manager can be put into place, such as CPU cache coherence and multiple implementation operation interdependence. | |
For now, this field should be set to 0 by clients.</em></strong></p> | |
<p>If the implementation cannot respond to the <span class="inline_code">implementation</span> flags set, it may return | |
a <span class="inline_code"><a href="#BVERR_IMPLEMENTATION">BVERR_IMPLEMENTATION</a></span> error.</p> | |
<p class="Code_Header_2"><a name="flags">bvbltparams.flags</a></p> | |
<p class="code_block">unsigned long flags; /* input */</p> | |
<p>The <span class="inline_code">flags</span> member provides the baseline of information to <span class="inline_code"> | |
<a href="#bv_blt">bv_blt()</a></span> about the type of BLT being requested.</p> | |
<p>To maintain compatibility, unused bits in the flags member should be set to 0.</p> | |
<p>If the flags set are not supported by the implementation, it may return <span class="inline_code"> | |
<a href="#BVERR_FLAGS">BVERR_FLAGS</a></span>, or a more specific <a href="#bverror">error code</a>.</p> | |
<p class="Code_Header_3"><a name="BVFLAG_OP_">bvbltparams.flags - BVFLAG_OP_*</a></p> | |
<p>The <span class="inline_code">op</span> field of the flags member specifies the type of BLT operation to perform. | |
Currently there are three types of BLT operations defined:</p> | |
<table class="indent"> | |
<tr> | |
<td valign="top">1.</td> | |
<td><span class="inline_code"><strong><a name="BVFLAG_ROP">BVFLAG_ROP</a></strong></span><br /> | |
<p>This flag indicates the operation being performed is a raster operation, and the <span class="inline_code"> | |
<a href="#op">bvbltparams.op</a></span> union is treated as <span class="inline_code"><a href="#rop">rop</a></span>. | |
Raster OPerations are binary operations performed on the bits of the inputs. See <span class="inline_code"> | |
<a href="#rop">bvbltparams.op.rop</a></span> for details.<br /> | |
<br /> | |
</p> | |
</td> | |
</tr> | |
<tr> | |
<td valign="top">2.</td> | |
<td> | |
<p><span class="inline_code"><strong><a name="BVFLAG_BLEND">BVFLAG_BLEND</a></strong></span><br /> | |
</p> | |
<p>This flag indicates the operation being performed is a blend, and the <span class="inline_code"> | |
<a href="#op">bvbltparams.op</a></span> union is treated as <span class="inline_code"><a href="#blend">blend</a></span>. | |
Blending involves mixing multiple layers of pixels using the specified equations. Surrounding pixels are not | |
involved in blend operations. See <span class="inline_code"><a href="#blend">bvbltparams.op.blend</a></span> | |
for details.<br /> | |
<br /> | |
</p> | |
</td> | |
</tr> | |
<tr> | |
<td valign="top">3.</td> | |
<td><span class="inline_code"><strong><a name="BVFLAG_FILTER">BVFLAG_FILTER</a></strong></span><br /> | |
<br /> | |
This flag indicates the operation being performed is a filter, and the <span class="inline_code"><a href="#op">bvbltparams.op</a></span> | |
union is treated as <span class="inline_code"><a href="#filter">filter</a></span>. Filtering involves mixing | |
multiple layers of pixels. Surrounding pixels are involved in filter operations. See | |
<span class="inline_code"><a href="#filter">bvbltparams.op.filter</a></span> for details.<br /> | |
</td> | |
</tr> | |
</table> | |
<p class="Code_Header_3"><a name="BVFLAG_KEY_SRC">bvbltparams.flags - BVFLAG_KEY_SRC</a>/<a name="BVFLAG_KEY_DST">DST</a></p> | |
<p>The <span class="inline_code">BVFLAG_KEY_SRC</span> and <span class="inline_code">BVFLAG_KEY_DST</span> enable source | |
and destination color keying, respectively. When either flag is set, the <span class="inline_code"> | |
<a href="#colorkey">colorkey</a></span> member of <span class="inline_code"><a href="#bvbltparams">bvbltparams</a></span> | |
is used.</p> | |
<p><span class="inline_code">BVFLAG_KEY_SRC</span> and <span class="inline_code">BVFLAG_KEY_DST</span> are mutually exclusive.</p> | |
<p>See <span class="inline_code"><a href="#colorkey">bvbltparams.colorkey</a></span> for details.</p> | |
<p class="Code_Header_3"><a name="BVFLAG_CLIP">bvbltparams.flags - BVFLAG_CLIP</a></p> | |
<p>When <span class="inline_code">BVFLAG_CLIP</span> is set, the <span class="inline_code"><a href="#cliprect">cliprect</a></span> | |
member of <span class="inline_code"><a href="#bvbltparams">bvbltparams</a></span> is used by the implementation as a limiting | |
rectangle on data written to the destination. See <span class="inline_code"><a href="#cliprect">cliprect</a></span> | |
for details.</p> | |
<p class="Code_Header_3"><a name="BVFLAG_SRCMASK">bvbltparams.flags - BVFLAG_SRCMASK</a></p> | |
<p>Normally, the mask is applied at the destination, after all scaling has been completed (including scaling the mask if | |
necessary). But some environments require that the mask be applied at the sources, before scaling occurs. The | |
<span class="inline_code">BVFLAG_SRCMASK</span> flag requests that the implementation use this method if supported.</p> | |
<p class="Code_Header_3">bvbltparams.flags - BVFLAG_TILE_*</p> | |
<p>Normally, when a source's size does not match the destination, the source is scaled to fill the destination. But | |
when the corresponding <span class="inline_code">BVFLAG_TILE_*</span> flag is set, this behavior is modified.</p> | |
<p>First, the source's size specifies a tile (or pattern, or brush) to be used to fill the destination. This tile | |
is replicated instead of scaled.</p> | |
<p>The origin of the source's rectangle is used to locate the tile within a larger surface. </p> | |
<p>Second, a <span class="inline_code"><a href="#bvbuffdesc">bvbuffdesc</a></span> object is no longer supplied by the client | |
in the bvbltparams structure. In its place is a <span class="inline_code"><a href="#bvtileparams">bvtileparams</a></span> | |
object.</p> | |
<p>Refer to the <span class="inline_code"><a href="#bvtileparams">bvtileparams</a></span> structure definition for details.</p> | |
<p class="Code_Header_3">bvbltparams.flags - <a name="BVFLAG_HORZ_FLIP">BVFLAG_HORZ</a>/<a name="BVFLAG_VERT_FLIP">VERT_FLIP_*</a></p> | |
<p>These flags indicate that the corresponding image is flipped horizontally or vertically as it is used by the operation.</p> | |
<p class="Code_Header_3">bvbltparams.flags - BVFLAG_SCALE/DITHER_RETURN</p> | |
<p>The scale and dither types can be specified with an implicit type. The implementation will then convert that internally | |
to an explicit scale or dither type. These flags request that the implementation return the explicit type chosen to | |
the client in the corresponding <span class="inline_code"><a href="#scalemode">bvbltparams.scalemode</a></span> and | |
<span class="inline_code"><a href="#dithermode">bvbltparams.dithermode</a></span> members.</p> | |
<p class="Code_Header_3">bvbltparams.flags - BVFLAG_ASYNC</p> | |
<p>This flag allows the client to inform the implementation that it can queue the requested BLT and return from | |
<span class="inline_code"><a href="#bv_blt">bv_blt()</a></span> before it has completed. If this bit is not set, when | |
the <span class="inline_code"><a href="#bv_blt">bv_blt()</a></span> returns, the operation is complete.</p> | |
<p>Normally, a client will also utilize the <span class="inline_code"><a href="#callbackfn">bvbltparams.callbackfn</a></span> | |
and <span class="inline_code"><a href="#callbackdata">bvbltparams.callbackdata</a></span> members to receive a notification | |
when the BLT has completed.</p> | |
<p class="note">NOTE: Asynchronous BLTs are performed in the order in which they are submitted within an implementation. | |
This was done to provide a simple dependency mechanism. | |
However, synchronization between implementations must be handled by the client, using the callback mechanism.</p> | |
<p class="note">NOTE: Since asynchronous BLTs are performed in the order in which they are submitted, it follows | |
that a synchronized BLT after a set of asynchronous BLTs may be used as synchronization as well.</p> | |
<p class="note"><a name="NOP">NOTE</a>: Certain situations may require manual synchronization without an associated BLT. | |
Rather than introduce an additional BLTsville function call, the method of handling this will be via a NOP BLT. To | |
accomplish a NOP BLT, the client should issue a BLT using the <span class="inline_code"><a href="#rop"> | |
bvbltparams.op.rop</a></span> code of <span class="inline_code">0xAAAA</span> (copy destination to destination), and | |
with the <span class="inline_code">BVFLAG_ASYNC</span> flag <span class="underline">not</span> set. Alternatively, the NOP BLT may set the | |
<span class="inline_code">BVFLAG_ASYNC</span> and provide a <span class="inline_code"><a href="#callbackfn"> | |
bvbltparams.callbackfn</a></span>. <em>To facilitate implementations, a valid destination surface should be | |
specified.</em></p> | |
<p class="imponly"><strong>Implementations Only<br /> | |
<br /> | |
</strong>In general, this BLTsville specification has avoided placing any requirement on implementations for specific | |
operations. However, in support of this special case, support for these NOP BLTs will need to be an implementation | |
<span class="underline"><strong>requirement</strong></span>. </p> | |
<p class="Code_Header_3">bvbltparams.flags - BVFLAG_BATCH_BEGIN/CONTINUE/END</p> | |
<p>These flags are used to control batching of BLTs for two main reasons:</p> | |
<ol> | |
<li>To group small, similar BLTs to consolidate overhead. For example, the BLTs associated with rendering each | |
character in a word.</li> | |
<li>To group related BLTs, which may allow an implementation to perform a more efficient, but equivalent set of operations.</li> | |
</ol> | |
<p>See <a href="#batching">Batching</a> for details.</p> | |
<p class="Code_Header_3">bvbltparams.flags - <a name="BVFLAG_SRC2_AUXDSTRECT">BVFLAG_SRC2</a>/<a name="BVFLAG_MASK_AUXDSTRECT">MASK_AUXDSTRECT</a></p> | |
<p>These flags are used to indicate that the bvbltparams.src2auxdstrect and bvbltparams.maskauxdstrect are to be used. | |
See these entries below for details. These flags are likely to be ignored except for the special case explained below, | |
so they should be used only when necessary.</p> | |
<p class="Code_Header_2"><a name="rop">bvbltparams.op.rop</a></p> | |
<p class="code_block">unsigned short op; /* input */ </p> | |
<p>When <span class="inline_code"><a href="#BVFLAG_ROP">BVFLAG_ROP</a></span> is set in the <span class="inline_code"> | |
<a href="#flags">bvbltparams.flags</a></span> member, the <span class="inline_code"><a href="#op">bvbltparams.op</a></span> | |
union is treated as <span class="inline_code">rop</span>. Raster OPerations are binary operations performed on the | |
bits of the inputs:</p> | |
<ul> | |
<li>ROP1s have one source: the destination. Two bits are sufficient to specify the four possible (2<sup>2</sup>) | |
ROP1 operations.</li> | |
<li>ROP2s have two sources: the destination and a source. Four bits are used to specify the sixteen (2<sup>2+2</sup>) | |
ROP2 operations.</li> | |
<li>ROP3s have three sources: the destination, a source (source 1), and a pattern (a.k.a. brush), which we call | |
source 2 in BLTsville. Eight bits are used to specify the 256 (2<sup>2+2+2</sup>) ROP3 operations.</li> | |
<li>ROP4s have four sources: the destination, two sources, and a mask. Sixteen bits are used to specify | |
the 65,536 (2<sup>2+2+2+2</sup>) ROP4 operations.</li> | |
</ul> | |
<p>BLTsville's <span class="inline_code">rop</span> element is used to specify a ROP4, but anything from ROP1 up to ROP4 | |
can be defined using this member:</p> | |
<ul> | |
<li>To specify an 8-bit ROP3 as a 16-bit ROP4, replicate the 8 bits twice: 0x2323.</li> | |
<li>To specify a 4-bit ROP2 as a 16-bit ROP4, replicate the 4 bits four times: 0x2222.</li> | |
<li>To specify a 2-bit ROP1 as a 16-bit ROP4, replicate the 2 bits eight times: 0x5555.</li> | |
</ul> | |
<p class="note">NOTE: | |
By far the most common ROP used will be 0xCCCC, which indicates a simple copy from source 1 to the destination.</p> | |
<p>The table below is the magic decoder ring: </p> | |
<table class="indent"> | |
<tr> | |
<td>Mask</td> | |
<td class="ctr"> 1 </td> | |
<td class="ctr"> 1 </td> | |
<td class="ctr"> 1 </td> | |
<td class="ctr"> 1 </td> | |
<td class="ctr"> 1 </td> | |
<td class="ctr"> 1 </td> | |
<td class="ctr"> 1 </td> | |
<td class="ctr"> 1 </td> | |
<td class="ctr"> 0 </td> | |
<td class="ctr"> 0 </td> | |
<td class="ctr"> 0 </td> | |
<td class="ctr"> 0 </td> | |
<td class="ctr"> 0 </td> | |
<td class="ctr"> 0 </td> | |
<td class="ctr"> 0 </td> | |
<td class="ctr"> 0 </td> | |
</tr> | |
<tr> | |
<td class="red_left">Source 2 </td> | |
<td class="red_center"> 1 </td> | |
<td class="red_center"> 1 </td> | |
<td class="red_center"> 1 </td> | |
<td class="red_center"> 1 </td> | |
<td class="red_center"> 0 </td> | |
<td class="red_center"> 0 </td> | |
<td class="red_center"> 0 </td> | |
<td class="red_center"> 0 </td> | |
<td class="red_center"> 1 </td> | |
<td class="red_center"> 1 </td> | |
<td class="red_center"> 1 </td> | |
<td class="red_center"> 1 </td> | |
<td class="red_center"> 0 </td> | |
<td class="red_center"> 0 </td> | |
<td class="red_center"> 0 </td> | |
<td class="red_center"> 0 </td> | |
</tr> | |
<tr> | |
<td class="grn_left">Source 1 </td> | |
<td class="grn_center"> 1 </td> | |
<td class="grn_center"> 1 </td> | |
<td class="grn_center"> 0 </td> | |
<td class="grn_center"> 0 </td> | |
<td class="grn_center"> 1 </td> | |
<td class="grn_center"> 1 </td> | |
<td class="grn_center"> 0 </td> | |
<td class="grn_center"> 0 </td> | |
<td class="grn_center"> 1 </td> | |
<td class="grn_center"> 1 </td> | |
<td class="grn_center"> 0 </td> | |
<td class="grn_center"> 0 </td> | |
<td class="grn_center"> 1 </td> | |
<td class="grn_center"> 1 </td> | |
<td class="grn_center"> 0 </td> | |
<td class="grn_center"> 0 </td> | |
</tr> | |
<tr> | |
<td class="blue_left_botbord">Destination </td> | |
<td class="blue_center_botbord"> 1 </td> | |
<td class="blue_center_botbord"> 0 </td> | |
<td class="blue_center_botbord"> 1 </td> | |
<td class="blue_center_botbord"> 0 </td> | |
<td class="blue_center_botbord"> 1 </td> | |
<td class="blue_center_botbord"> 0 </td> | |
<td class="blue_center_botbord"> 1 </td> | |
<td class="blue_center_botbord"> 0 </td> | |
<td class="blue_center_botbord"> 1 </td> | |
<td class="blue_center_botbord"> 0 </td> | |
<td class="blue_center_botbord"> 1 </td> | |
<td class="blue_center_botbord"> 0 </td> | |
<td class="blue_center_botbord"> 1 </td> | |
<td class="blue_center_botbord"> 0 </td> | |
<td class="blue_center_botbord"> 1 </td> | |
<td class="blue_center_botbord"> 0 </td> | |
</tr> | |
<tr> | |
<td class="left_topbord">Raster Operation </td> | |
<td class="center_topbord"> 15 </td> | |
<td class="center_topbord"> 14 </td> | |
<td class="center_topbord"> 13 </td> | |
<td class="center_topbord"> 12 </td> | |
<td class="center_topbord"> 11 </td> | |
<td class="center_topbord"> 10 </td> | |
<td class="center_topbord"> 9 </td> | |
<td class="center_topbord"> 8 </td> | |
<td class="center_topbord"> 7 </td> | |
<td class="center_topbord"> 6 </td> | |
<td class="center_topbord"> 5 </td> | |
<td class="center_topbord"> 4 </td> | |
<td class="center_topbord"> 3 </td> | |
<td class="center_topbord"> 2 </td> | |
<td class="center_topbord"> 1 </td> | |
<td class="center_topbord"> 0 </td> | |
</tr> | |
</table> | |
<br /> | |
For example, to specify an operation that uses the mask to choose between source 1 and destination (source 1 when mask is | |
1, destination when mask is 0), a client would calculate the bottom line by parsing each column:<br /> | |
<br /> | |
When mask is 1 (the first eight columns), the <span class="inline_code">rop</span> matches the source 1 row. When | |
mask is 0 (the last eight columns), the <span class="inline_code">rop</span> matches the destination row.<br /> | |
<br /> | |
<table class="indent"> | |
<tr> | |
<td class="left_topbord">Raster Operation </td> | |
<td class="red_center_topbord"> 1 </td> | |
<td class="red_center_topbord"> 1 </td> | |
<td class="red_center_topbord"> 1 </td> | |
<td class="red_center_topbord"> 1 </td> | |
<td class="red_center_topbord"> 0 </td> | |
<td class="red_center_topbord"> 0 </td> | |
<td class="red_center_topbord"> 0 </td> | |
<td class="red_center_topbord"> 0 </td> | |
<td class="blu_center_topbord"> 1 </td> | |
<td class="blu_center_topbord"> 0 </td> | |
<td class="blu_center_topbord"> 1 </td> | |
<td class="blu_center_topbord"> 0 </td> | |
<td class="blu_center_topbord"> 1 </td> | |
<td class="blu_center_topbord"> 0 </td> | |
<td class="blu_center_topbord"> 1 </td> | |
<td class="blu_center_topbord"> 0 </td> | |
</tr> | |
</table> | |
<br /> | |
So the <span class="inline_code">rop</span> for this operation would be 0xF0AA.<br /> | |
<br /> | |
Here is a list of some commonly used raster operations that have been given names:<br /> | |
<br /> | |
<table class="indent_thick_bord"> | |
<tr> | |
<td class="thin_bord_dbl_botbord"><strong>ROP </strong></td> | |
<td class="thin_bord_dbl_botbord"><strong>Constant</strong></td> | |
<td class="thin_bord_dbl_botbord"><strong>Description</strong></td> | |
</tr> | |
<tr> | |
<td class="thin_bord">BLACKNESS</td> | |
<td class="thin_bord">0x0000</td> | |
<td class="thin_bord">Set all destination bits to black (0). Dest = 0</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">NOTSRCERASE</td> | |
<td class="thin_bord">0x1111</td> | |
<td class="thin_bord">Dest = ~Src1 & ~Dest = ~(Src1 | Dest)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">NOTSRCCOPY</td> | |
<td class="thin_bord">0x3333</td> | |
<td class="thin_bord">Dest = ~Src1</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">SRCERASE</td> | |
<td class="thin_bord">0x4444</td> | |
<td class="thin_bord">Dest = Src1 & ~Dest</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">DSTINVERT</td> | |
<td class="thin_bord">0x5555</td> | |
<td class="thin_bord">Invert (NOT) the destination bits. Dest = ~Dest</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">PATINVERT</td> | |
<td class="thin_bord">0x5A5A</td> | |
<td class="thin_bord">XOR with Src2. Dest = Src2 ^ Dest</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">SRCINVERT</td> | |
<td class="thin_bord">0x6666</td> | |
<td class="thin_bord">XOR with Src1. Dest = Src1 ^ Dest</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">SRCAND</td> | |
<td class="thin_bord">0x8888</td> | |
<td class="thin_bord">Dest = Src1 & Dest</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">NOP</td> | |
<td class="thin_bord">0xAAAA</td> | |
<td class="thin_bord">Dest = Dest</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">MERGEPAINT</td> | |
<td class="thin_bord">0xBBBB</td> | |
<td class="thin_bord">Dest = ~Src1 | Dest</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">MERGECOPY</td> | |
<td class="thin_bord">0xC0C0</td> | |
<td class="thin_bord">Dest = Src1 & Src2</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">SRCCOPY</td> | |
<td class="thin_bord">0xCCCC</td> | |
<td class="thin_bord">Dest = Src1</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">SRCPAINT</td> | |
<td class="thin_bord">0xEEEE</td> | |
<td class="thin_bord">OR with Src1. Dest = Src1 | Dest</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">PATCOPY</td> | |
<td class="thin_bord">0xF0F0</td> | |
<td class="thin_bord">Copy source 2 to destination. Dest = Src2</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">PATPAINT</td> | |
<td class="thin_bord">0xFBFB</td> | |
<td class="thin_bord">Dest = ~Src1 | Src2 | Dest</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">WHITENESS</td> | |
<td class="thin_bord">0xFFFF</td> | |
<td class="thin_bord">Set all destination bits to white (1). Dest = 1</td> | |
</tr> | |
</table> | |
<br /> | |
<span class="Code_Header_2"><a name="blend">bvbltparams.op.blend</a></span> | |
<p class="code_block">enum bvblend blend; /* input */</p> | |
<p>When <span class="inline_code"><a href="#BVFLAG_BLEND">BVFLAG_BLEND</a></span> is set in the | |
<span class="inline_code"><a href="#flags">bvbltparams.flags</a></span> member, the <span class="inline_code"> | |
<a href="#op">bvbltparams.op</a></span> union is treated as a <span class="inline_code">blend</span>.</p> | |
<p>To specify the blend, the client fills in <span class="inline_code">blend</span> with one of the | |
<span class="inline_code"><a href="#bvblend">bvblend</a></span> values.</p> | |
<p><span class="inline_code"><a href="#bvblend">bvblend</a></span> is an enumeration assembled from sets of fields. | |
The values specified may be extended beyond those that are explicitly defined using the definitions in the | |
<span class="filename">bvblend.h</span> header file.</p> | |
<p>The first 4 bits are the format. Currently two format groups are defined, but others can be added. The remainder | |
of the bits are used as defined by the individual format:</p> | |
<table class="indent"> | |
<tr> | |
<td valign="top">1.</td> | |
<td><span class="Code_Header_3">BVBLENDDEF_FORMAT_CLASSIC</span><br /> | |
<br /> | |
The <span class="inline_code">BVBLENDDEF_FORMAT_CLASSIC</span> is meant to handle the classic Porter-Duff equations. | |
It can also handle the DirectFB blending.<br /> | |
<br /> | |
<span class="inline_code">BVBLENDDEF_FORMAT_CLASSIC</span> is based on the following equations:<br /> | |
<div> | |
<p class="indent">C<sub>d</sub> = K<sub>1</sub>C<sub>1</sub> + K<sub>2</sub>C<sub>2</sub><br /> | |
A<sub>d</sub> = K<sub>3</sub>A<sub>1</sub> + K<sub>4</sub>A<sub>2</sub></p> | |
</div> | |
where:<br /> | |
<div> | |
<p class="indent">C<sub>d</sub>: destination color<br /> | |
C<sub>1</sub>: source 1 color<br /> | |
C<sub>2</sub>: source 2 color<br /> | |
A<sub>d</sub>: destination alpha<br /> | |
A<sub>1</sub>: source 1 alpha<br /> | |
A<sub>2</sub>: source 2 alpha<br /> | |
K<sub>#</sub>: one of the constants defined using the bitfields below</p> | |
</div> | |
The 28 bits for <span class="inline_code">BVBLENDDEF_FORMAT_CLASSIC</span> are divided into 5 sections.<br /> | |
<br /> | |
The most significant 4 bits are modifiers, used to include additional alpha values from global or remote sources.<br /> | |
<br /> | |
[27] The most significant bit indicates that a remote alpha is to be included in the blend. The format of this is | |
defined by <span class="inline_code"><a href="#maskgeom">bvbltparams.maskgeom.format</a></span>.<br /> | |
<br /> | |
[26] The next bit is reserved.<br /> | |
<br /> | |
[25:24] The next 2 bits are used to indicate that a global alpha is to be included, and what its format is:<br /> | |
<div> | |
<p class="indent">00: no global included<br /> | |
01: global included; bvbltparams.globalalpha.size8 is used (0 -> 255)<br /> | |
10: this value is reserved<br /> | |
11: global included; bvbltparams.flogalalpha.fp is used (0.0 -> 1.0) </p> | |
</div> | |
The remaining bits are divided into 4 sections, one to define each of the constants:<br /> | |
<br /> | |
[23:18] - K1<br /> | |
[17:12] - K2<br /> | |
[11:6] - K3<br /> | |
[5:0] - K4<br /> | |
<br /> | |
The format is the same for all 4 constant fields:<br /> | |
<br /> | |
[5:4] The first 2 bits of each field indicates the way in which the other 2 fields are interpreted:<br /> | |
<div> | |
<p class="indent">00: only As: the other two fields contain only As; there should be only one valid A value | |
between the two fields<br /> | |
01: minimum: the value of the constant is the minimum of the two fields<br /> | |
10: maximum: the value of the constant is the maximum of the two fields<br /> | |
11: only Cs: the other two fields contain only Cs; there should be only one valid C value between the two fields</p> | |
</div> | |
[3:2] The middle 2 bits of each field contain the inverse field:<br /> | |
<div> | |
<p class="indent">00: 1-C1 ("don't care" for "only As")<br /> | |
01: 1-A1 ("don't care" for "only Cs")<br /> | |
10: 1-C2 ("don't care" for "only As")<br /> | |
11: 1-A2 ("don't care" for "only Cs")</p> | |
</div> | |
[1:0] The last 2 bits if each field contain the normal field:<br /> | |
<div> | |
<p class="indent">00: C1 ("don't care" for "only As")<br /> | |
01: A1 ("don't care" for "only Cs")<br /> | |
10: C2 ("don't care" for "only As")<br /> | |
11: A2 ("don't care" for "only Cs")</p> | |
</div> | |
EXCEPTIONS:<br /> | |
<br /> | |
00 00 00 - The value 00 00 00, which normally would indicate "only As" with two "don't care" fields, is interpreted | |
as a constant of 0.<br /> | |
<br /> | |
11 11 11 - The value 11 11 11, which normally would indicate "only Cs" with two "don't care" fields, is interpreted | |
as a constant of 1.<br /> | |
<br /> | |
<span class="Header4">Constants</span><br /> | |
<br /> | |
Put together, these can define portions of the blend equations that can be put together in a variety of ways:<br /> | |
<br /> | |
<table class="indent_thick_bord"> | |
<tr> | |
<td class="rt_thick_bord"> | |
<table> | |
<tr> | |
<td class="thin_bord">00 00 00</td> | |
<td class="thin_bord">undefined -> zero</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">00 00 01</td> | |
<td class="thin_bord">A1 (preferred)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">00 00 10</td> | |
<td class="thin_bord">undefined</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">00 00 11</td> | |
<td class="thin_bord">A2 (preferred)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">00 01 00</td> | |
<td class="thin_bord">1-A1 (preferred)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">00 01 01</td> | |
<td class="thin_bord">undefined</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">00 01 10</td> | |
<td class="thin_bord">1-A1 (use 00 01 00)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">00 01 11</td> | |
<td class="thin_bord">undefined</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">00 10 00</td> | |
<td class="thin_bord">undefined</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">00 10 01</td> | |
<td class="thin_bord">A1 (use 00 00 01)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">00 10 10</td> | |
<td class="thin_bord">undefined</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">00 10 11</td> | |
<td class="thin_bord">A2 (use 00 00 11)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">00 11 00</td> | |
<td class="thin_bord">1-A2 (preferred)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">00 11 01</td> | |
<td class="thin_bord">undefined</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">00 11 10</td> | |
<td class="thin_bord">1-A2 (use 00 11 00)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">00 11 11</td> | |
<td class="thin_bord">undefined</td> | |
</tr> | |
</table> | |
</td> | |
<td class="rt_thick_bord"> | |
<table> | |
<tr> | |
<td class="thin_bord">01 00 00</td> | |
<td class="thin_bord">min(C1,1-C1)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">01 00 01</td> | |
<td class="thin_bord">min(A1,1-C1)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">01 00 10</td> | |
<td class="thin_bord">min(C2,1-C1)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">01 00 11</td> | |
<td class="thin_bord">min(A2,1-C1)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">01 01 00</td> | |
<td class="thin_bord">min(C1,1-A1)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">01 01 01</td> | |
<td class="thin_bord">min(A1,1-A1)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">01 01 10</td> | |
<td class="thin_bord">min(C2,1-A1)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">01 01 11</td> | |
<td class="thin_bord">min(A2,1-A1)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">01 10 00</td> | |
<td class="thin_bord">min(C1,1-C2)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">01 10 01</td> | |
<td class="thin_bord">min(A1,1-C2)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">01 10 10</td> | |
<td class="thin_bord">min(C2,1-C2)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">01 10 11</td> | |
<td class="thin_bord">min(A2,1-C2)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">01 11 00</td> | |
<td class="thin_bord">min(C1,1-A2)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">01 11 01</td> | |
<td class="thin_bord">min(A1,1-A2)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">01 11 10</td> | |
<td class="thin_bord">min(C2,1-A2)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">01 11 11</td> | |
<td class="thin_bord">min(A2,1-A2)</td> | |
</tr> | |
</table> | |
</td> | |
<td class="rt_thick_bord"> | |
<table> | |
<tr> | |
<td class="thin_bord">10 00 00</td> | |
<td class="thin_bord">max(C1,1-C1)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">10 00 01</td> | |
<td class="thin_bord">max(A1,1-C1)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">10 00 10</td> | |
<td class="thin_bord">max(C2,1-C1)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">10 00 11</td> | |
<td class="thin_bord">max(A2,1-C1)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">10 01 00</td> | |
<td class="thin_bord">max(C1,1-A1)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">10 01 01</td> | |
<td class="thin_bord">max(A1,1-A1)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">10 01 10</td> | |
<td class="thin_bord">max(C2,1-A1)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">10 01 11</td> | |
<td class="thin_bord">max(A2,1-A1)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">10 10 00</td> | |
<td class="thin_bord">max(C1,1-C2)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">10 10 01</td> | |
<td class="thin_bord">max(A1,1-C2)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">10 10 10</td> | |
<td class="thin_bord">max(C2,1-C2)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">10 10 11</td> | |
<td class="thin_bord">max(A2,1-C2)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">10 11 00</td> | |
<td class="thin_bord">max(C1,1-A2)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">10 11 01</td> | |
<td class="thin_bord">max(A1,1-A2)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">10 11 10</td> | |
<td class="thin_bord">max(C2,1-A2)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">10 11 11</td> | |
<td class="thin_bord">max(A2,1-A2)</td> | |
</tr> | |
</table> | |
</td> | |
<td> | |
<table> | |
<tr> | |
<td class="thin_bord">11 00 00</td> | |
<td class="thin_bord">undefined</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">11 00 01</td> | |
<td class="thin_bord">1-C1 (use 11 00 11)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">11 00 10</td> | |
<td class="thin_bord">undefined</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">11 00 11</td> | |
<td class="thin_bord">1-C1 (preferred)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">11 01 00</td> | |
<td class="thin_bord">C1 (use 11 11 00)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">11 01 01</td> | |
<td class="thin_bord">undefined</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">11 01 10</td> | |
<td class="thin_bord">C2 (use 11 11 10)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">11 01 11</td> | |
<td class="thin_bord">undefined</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">11 10 00</td> | |
<td class="thin_bord">undefined</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">11 10 01</td> | |
<td class="thin_bord">1-C2 (use 11 10 11)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">11 10 10</td> | |
<td class="thin_bord">undefined</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">11 10 11</td> | |
<td class="thin_bord">1-C2 (preferred)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">11 11 00</td> | |
<td class="thin_bord">C1 (preferred)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">11 11 01</td> | |
<td class="thin_bord">undefined</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">11 11 10</td> | |
<td class="thin_bord">C2 (preferred)</td> | |
</tr> | |
<tr> | |
<td class="thin_bord">11 11 11</td> | |
<td class="thin_bord">undefined -> one</td> | |
</tr> | |
</table> | |
</td> | |
</tr> | |
</table> | |
<span class="Header4"><br /> | |
DirectFB Example</span><br /> | |
<br /> | |
Putting these together into the proper constants, the blending equations can be built for different APIs. | |
Here is how DirectFB would be mapped:<br /> | |
<br /> | |
For DirectFB, the | |
<a href="http://directfb.org/docs/DirectFB_Reference_1_2/IDirectFBSurface_SetSrcBlendFunction.html" class="inline_code"> | |
SetSrcBlendFunction()</a> and | |
<a href="http://directfb.org/docs/DirectFB_Reference_1_2/IDirectFBSurface_SetDstBlendFunction.html" class="inline_code"> | |
SetDstBlendFunction()</a> can specify 121 combinations of blends (11 x 11). It's impractical to specify these combinations | |
individually. Instead, the settings indicated by each call should be bitwise OR'd to make the proper single value | |
used in BLTsville.<br /> | |
<br /> | |
<table class="code_block"> | |
<tr> | |
<td class="ctr"> </td> | |
<td colspan="5" class="ctr"><strong>32-bit Binary Value</strong></td> | |
</tr> | |
<tr> | |
<td><strong> | |
<a href="http://directfb.org/docs/DirectFB_Reference_1_2/IDirectFBSurface_SetSrcBlendFunction.html">SetSrcBlendFunction()</a></strong></td> | |
<td class="ctr"><strong>[VendorID]</strong></td> | |
<td class="ctr"><strong> [--K1--] </strong></td> | |
<td class="ctr"><strong> [--K2--] </strong></td> | |
<td class="ctr"><strong> [--K3--] </strong></td> | |
<td class="ctr"><strong> [--K4--] </strong></td> | |
</tr> | |
<tr> | |
<td>DSBF_ZERO</td> | |
<td class="ctr">0000 0000</td> | |
<td class="ctr">00 00 00</td> | |
<td class="ctr">xx xx xx</td> | |
<td class="ctr">00 00 00</td> | |
<td class="ctr">xx xx xx</td> | |
</tr> | |
<tr> | |
<td>DSBF_ONE</td> | |
<td class="ctr">0000 0000</td> | |
<td class="ctr">11 11 11</td> | |
<td class="ctr">xx xx xx</td> | |
<td class="ctr">11 11 11</td> | |
<td class="ctr">xx xx xx</td> | |
</tr> | |
<tr> | |
<td>DSBF_SRCCOLOR</td> | |
<td class="ctr">0000 0000</td> | |
<td class="ctr">11 11 00</td> | |
<td class="ctr">xx xx xx</td> | |
<td class="ctr">00 00 01</td> | |
<td class="ctr">xx xx xx</td> | |
</tr> | |
<tr> | |
<td>DSBF_INVSRCCOLOR</td> | |
<td class="ctr">0000 0000</td> | |
<td class="ctr">11 00 11</td> | |
<td class="ctr">xx xx xx</td> | |
<td class="ctr">00 01 00</td> | |
<td class="ctr">xx xx xx</td> | |
</tr> | |
<tr> | |
<td>DSBF_SRCALPHA</td> | |
<td class="ctr">0000 0000</td> | |
<td class="ctr">00 00 01</td> | |
<td class="ctr">xx xx xx</td> | |
<td class="ctr">00 00 01</td> | |
<td class="ctr">xx xx xx</td> | |
</tr> | |
<tr> | |
<td>DSBF_INVSRCALPHA</td> | |
<td class="ctr">0000 0000</td> | |
<td class="ctr">00 01 00</td> | |
<td class="ctr">xx xx xx</td> | |
<td class="ctr">00 01 00</td> | |
<td class="ctr">xx xx xx</td> | |
</tr> | |
<tr> | |
<td>DSBF_DESTCOLOR</td> | |
<td class="ctr">0000 0000</td> | |
<td class="ctr">11 11 10</td> | |
<td class="ctr">xx xx xx</td> | |
<td class="ctr">00 00 11</td> | |
<td class="ctr">xx xx xx</td> | |
</tr> | |
<tr> | |
<td>DSBF_INVDESTCOLOR</td> | |
<td class="ctr">0000 0000</td> | |
<td class="ctr">11 10 11</td> | |
<td class="ctr">xx xx xx</td> | |
<td class="ctr">00 11 00</td> | |
<td class="ctr">xx xx xx</td> | |
</tr> | |
<tr> | |
<td>DSBF_DESTALPHA</td> | |
<td class="ctr">0000 0000</td> | |
<td class="ctr">00 00 11</td> | |
<td class="ctr">xx xx xx</td> | |
<td class="ctr">00 00 11</td> | |
<td class="ctr">xx xx xx</td> | |
</tr> | |
<tr> | |
<td>DSBF_INVDESTALPHA</td> | |
<td class="ctr">0000 0000</td> | |
<td class="ctr">00 11 00</td> | |
<td class="ctr">xx xx xx</td> | |
<td class="ctr">00 11 00</td> | |
<td class="ctr">xx xx xx</td> | |
</tr> | |
<tr> | |
<td>DSBF_SRCALPHASAT</td> | |
<td class="ctr">0000 0000</td> | |
<td class="ctr">01 11 01</td> | |
<td class="ctr">xx xx xx</td> | |
<td class="ctr">11 11 11</td> | |
<td class="ctr">xx xx xx</td> | |
</tr> | |
</table> | |
<br /> | |
<table class="code_block"> | |
<tr> | |
<td class="ctr"> </td> | |
<td colspan="5" class="ctr"><strong>32-bit Binary Value</strong></td> | |
</tr> | |
<tr> | |
<td><strong> | |
<a href="http://directfb.org/docs/DirectFB_Reference_1_2/IDirectFBSurface_SetDstBlendFunction.html">SetDstBlendFunction()</a></strong></td> | |
<td class="ctr"><strong>[VendorID]</strong></td> | |
<td class="ctr"><strong> [--K1--] </strong></td> | |
<td class="ctr"><strong> [--K2--] </strong></td> | |
<td class="ctr"><strong> [--K3--] </strong></td> | |
<td class="ctr"><strong> [--K4--] </strong></td> | |
</tr> | |
<tr> | |
<td>DSBF_ZERO</td> | |
<td class="ctr">0000 0000</td> | |
<td class="ctr">xx xx xx</td> | |
<td class="ctr">00 00 00</td> | |
<td class="ctr">xx xx xx</td> | |
<td class="ctr">00 00 00</td> | |
</tr> | |
<tr> | |
<td>DSBF_ONE</td> | |
<td class="ctr">0000 0000</td> | |
<td class="ctr">xx xx xx</td> | |
<td class="ctr">11 11 11</td> | |
<td class="ctr">xx xx xx</td> | |
<td class="ctr">11 11 11</td> | |
</tr> | |
<tr> | |
<td>DSBF_SRCCOLOR</td> | |
<td class="ctr">0000 0000</td> | |
<td class="ctr">xx xx xx</td> | |
<td class="ctr">11 11 00</td> | |
<td class="ctr">xx xx xx</td> | |
<td class="ctr">00 00 01</td> | |
</tr> | |
<tr> | |
<td>etc.</td> | |
<td class="ctr"> </td> | |
<td class="ctr"> </td> | |
<td class="ctr"> </td> | |
<td class="ctr"> </td> | |
<td> </td> | |
</tr> | |
</table> | |
<br /> | |
<span class="Header4">Porter-Duff</span><br /> | |
<br /> | |
For Porter-Duff blends, the equations can be more specifically defined. For convenience, these are enumerated in | |
the <span class="inline_code">bvblend.h</span> header. These enumerations utilize only the local alpha in the equations | |
as indicated. To use global or remote alpha, these enumerations need to be modified. For example, to include the | |
global alpha in the Porter-Duff <span class="inline_code">BVBLEND_SRC1OVER</span> blend, the blend could be defined | |
like this:<br /> | |
<br /> | |
<div> | |
<table class="indent"> | |
<tr> | |
<td valign="top"><span class="inline_code">params.op.blend =</span></td> | |
<td><span class="inline_code">BVBLEND_SRC1OVER +<br /> | |
BVBLENDDEF_GLOBAL_UCHAR;</span></td> | |
</tr> | |
</table> | |
</div> | |
<br /> | |
To include the remote alpha, the blend could be defined like this:<br /> | |
<br /> | |
<div> | |
<table class="indent"> | |
<tr> | |
<td valign="top"><span class="inline_code">params.op.blend =</span></td> | |
<td><span class="inline_code">BVBLEND_SRC1OVER +<br /> | |
BVBLENDDEF_REMOTE;</span></td> | |
</tr> | |
</table> | |
</div> | |
<br /> | |
And to include both:<br /> | |
<br /> | |
<div> | |
<table class="indent"> | |
<tr> | |
<td valign="top"><span class="inline_code">params.op.blend =</span></td> | |
<td><span class="inline_code">BVBLEND_SRC1OVER +<br /> | |
BVBLENDDEF_GLOBAL_UCHAR +<br /> | |
BVBLENDDEF_REMOTE;</span></td> | |
</tr> | |
</table> | |
</div> | |
<br /> | |
Note that if the source color formats include local alphas, the local alphas, global alpha, and remote alpha will | |
be used together.<br /> | |
<br /> | |
Note also that the equations assume the surfaces are premultiplied. So if the surface formats indicate that they | |
are not premultiplied, the alpha multiplication of each color is done prior to using the surface values in the equations.<br /> | |
<br /> | |
For example, <span class="inline_code">BVBLEND_SRC1OVER</span> specifies the equations:<br /> | |
<table class="indent"> | |
<tr> | |
<td>C<sub>d</sub> = C<sub>1</sub> + (1 - A<sub>1</sub>)C<sub>2</sub><br /> | |
A<sub>d</sub> = A<sub>1</sub> + (1 - A<sub>1</sub>)A<sub>2</sub> </td> | |
</tr> | |
</table> | |
<br /> | |
If the format of surface 1 is non-premultiplied, the equations are modified to include the multiplication explicitly:<br /> | |
<br /> | |
<table class="indent"> | |
<tr> | |
<td>C<sub>d</sub> = A<sub>1</sub>C<sub>1</sub> + (1 - A<sub>1</sub>)C<sub>2</sub><br /> | |
A<sub>d</sub> = A<sub>1</sub> + (1 - A<sub>1</sub>)A<sub>2</sub> </td> | |
</tr> | |
</table> | |
<br /> | |
Likewise, if the format of surface 2 is non-premultiplied, the equations are modified for this:<br /> | |
<br /> | |
<table class="indent"> | |
<tr> | |
<td> | |
<div> | |
C<sub>d</sub> = C<sub>1</sub> + (1 - A<sub>1</sub>)A<sub>2</sub>C<sub>2</sub><br /> | |
A<sub>d</sub> = A<sub>1</sub> + (1 - A<sub>1</sub>)A<sub>2</sub> </div> | |
</td> | |
</tr> | |
</table> | |
<br /> | |
When including global or remote alphas, these values are used to modify the source 1 value values before being used | |
in the blend equation:<br /> | |
<br /> | |
<table class="indent"> | |
<tr> | |
<td class="ctr">C<sub>1</sub> = A<sub>g</sub>C<sub>1</sub><br /> | |
A<sub>1</sub> = A<sub>g</sub>A<sub>1</sub></td> | |
<td style="width: 20%" class="ctr">-or-</td> | |
<td class="ctr">C<sub>1</sub> = A<sub>r</sub>C<sub>1</sub><br /> | |
A<sub>1</sub> = A<sub>r</sub>A<sub>1</sub></td> | |
<td class="ctr">-or-</td> | |
<td class="ctr">C<sub>1</sub> = A<sub>r</sub>A<sub>g</sub>C<sub>1</sub><br /> | |
A<sub>1</sub> = A<sub>r</sub>A<sub>g</sub>A<sub>1</sub></td> | |
</tr> | |
</table> | |
<br /> | |
</td> | |
</tr> | |
<tr> | |
<td valign="top">2.</td> | |
<td><span class="Code_Header_3"><strong><a name="BVBLENDDEF_FORMAT_ESSENTIAL0">BVBLENDDEF_FORMAT_ESSENTIAL</a></strong></span><br /> | |
<br /> | |
The essential blending equations are based on the blending equations in common image manipulation programs.<pre class="indent"><code>BVBLEND_LIGHTEN max(src1, src2) | |
BVBLEND_DARKEN min(src1, src2) | |
BVBLEND_MULTIPLY (src1 * src2) / 255 | |
BVBLEND_AVERAGE (src1 + src2) / 2 | |
BVBLEND_ADD src1 + src2 (saturated) | |
BVBLEND_SUBTRACT src1 + src2 - 255 (saturated) | |
BVBLEND_DIFFERENCE abs(src - src2) | |
BVBLEND_NEGATION 255 - abs(255 - src1 - src2) | |
BVBLEND_SCREEN 255 - (((255 - src1) * (255 - src2)) / 256) | |
BVBLEND_EXCLUSION src1 + src2 - ((2 * src1 * src2) / 255) | |
BVBLEND_OVERLAY (src2 < 128) ? (2 * src1 * src2 / 255) : (255 - 2 * (255 - src1) * (255 - src2) / 255) | |
BVBLEND_SOFT_LIGHT (src2 < 128) ? (2 * ((src1 >> 1) + 64)) * ((float)src2 / 255) : (255 - (2 * (255 - ((src1 >> 1) + 64)) * (float)(255 - src2) / 255)) | |
BVBLEND_HARD_LIGHT (src1 < 128) ? (2 * src2 * src1 / 255) : (255 - 2 * (255 - src2) * (255 - src1) / 255) | |
BVBLEND_COLOR_DODGE (src2 == 255) ? src2 : min(255, ((src1 << 8) / (255 - src2)) | |
BVBLEND_COLOR_BURN (src2 == 0) ? src2 : max(0, (255 - ((255 - src1) << 8 ) / src2)))) | |
BVBLEND_LINEAR_DODGE same as BVBLEND_ADD | |
BVBLEND_LINEAR_BURN same as BVBLEND_SUBTRACT | |
BVBLEND_LINEAR_LIGHT (src2 < 128) ? LINEAR_BURN(src1,(2 * src2)) : LINEAR_DODGE(src1,(2 * (src2 - 128))) | |
BVBLEND_VIVID_LIGHT (src2 < 128) ? COLOR_BURN(src1,(2 * src2)) : COLOR_DODGE(src1,(2 * (src2 - 128)))) | |
BVBLEND_PIN_LIGHT (src2 < 128) ? DARKEN(src1,(2 * src2)) : LIGHTEN(src1,(2 * (src2 - 128))) | |
BVBLEND_HARD_MIX (VIVID_LIGHT(src1, src2) < 128) ? 0 : 255 | |
BVBLEND_REFLECT (src2 == 255) ? src2 : min(255, (src1 * src1 / (255 - src2))) | |
BVBLEND_GLOW (src1 == 255) ? src1 : min(255, (src2 * src2 / (255 - src1))) | |
BVBLEND_PHOENIX min(src1, src2) - max(src1, src2) + 255) | |
BVBLEND_ALPHA alf * src1 + (1 - alf) * src2)</code></pre> | |
</td> | |
</tr> | |
</table> | |
<a name="filter" class="Code_Header_2">bvbltparams.op.filter</a> | |
<p class="code_block">struct bvfilter *filter; /* input */</p> | |
<p>When <span class="inline_code"><a href="#BVFLAG_FILTER">BVFLAG_FILTER</a></span> is set in the | |
<span class="inline_code"><a href="#flags">bvbltparams.flags</a></span> member, the <span class="inline_code"> | |
<a href="#op">bvbltparams.op</a></span> union is treated as a <span class="inline_code">filter</span>.</p> | |
<p>To specify the filter, the client fills in <span class="inline_code">filter</span> with one of the | |
<span class="inline_code">bvfilter</span> values.</p> | |
<p>These values will be extended as general filter types are requested.</p> | |
<a name="colorkey" class="Code_Header_2">bvbltparams.colorkey</a> | |
<p class="code_block">void *colorkey; /* input */</p> | |
<p>When either <span class="inline_code"><a href="#BVFLAG_KEY_SRC">BVFLAG_KEY_SRC</a></span> or | |
<span class="inline_code"><a href="#BVFLAG_KEY_DST">BVFLAG_KEY_DST</a></span> is set in the <span class="inline_code"> | |
<a href="#flags">bvbltparams.flags</a></span> member, <span class="inline_code">colorkey</span> points to a single pixel | |
used as the color key.</p> | |
<p>The format of this pixel matches the surface being keyed. i.e. <span class="inline_code"><a href="#bvsurfgeom"> | |
src1geom.format</a></span> is the format of the color key if <span class="inline_code">BVFLAG_KEY_SRC</span> is set, or | |
<span class="inline_code"><a href="#bvsurfgeom">dst.format</a></span> is the format of the color key if | |
<span class="inline_code">BVFLAG_KEY_DST</span> is set.</p> | |
<p><em>Subsampled formats do not currently support color keying.</em></p> | |
<p class="Code_Header_2"><a name="globalalpha">bvbltparams.globalalpha</a></p> | |
<p class="code_block">union bvalpha globalalpha; /* input */</p> | |
<p>When <span class="inline_code"><a href="#BVFLAG_BLEND">BVFLAG_BLEND</a></span> is set in the | |
<span class="inline_code"><a href="#flags">bvbltparams.flags</a></span>, and when the <span class="inline_code"> | |
<a href="#blend">blend</a></span> chosen requires it, <span class="inline_code">globalalpha</span> is used to provide an | |
alpha blending value for the entire operation. The type is also dependent on the <span class="inline_code"> | |
<a href="#blend">blend</a></span> chosen.</p> | |
<p>For the <span class="inline_code">BVBLENDDEF_FORMAT_CLASSIC</span> blend types, if the <span class="inline_code">BVBLENDDEF_GLOBAL_MASK</span> | |
field is not 0, this field is used. Currently <span class="inline_code">BVBLENDDEF_FORMAT_CLASSIC</span> provides | |
for an 8-bit (unsigned character / byte) format designated by <span class="inline_code">BVBLENDDEF_GLOBAL_UCHAR</span> as | |
well as a 32-bit floating point format designated by <span class="inline_code">BVBLENDDEF_GLOBAL_FLOAT</span>.</p> | |
<p class="Code_Header_2"><a name="scalemode">bvbltparams.scalemode</a></p> | |
<p class="code_block">enum bvscalemode scalemode; /* input/output */</p> | |
<p>This member allows the client to specify the type of scaling to be used. The enumeration begins with 8 bits indicating | |
the vendor. The remaining bits are defined by the vendor. <span class="inline_code">BVSCALEDEF_VENDOR_ALL</span> | |
and <span class="inline_code">BVSCALEDEF_VENDOR_GENERAL</span> are shared by all implementations.</p> | |
<p><span class="inline_code">BVSCALEDEF_VENDOR_ALL</span> can be used to specify an implicit scale type. This type | |
is converted to an explicit type by the implementation:</p> | |
<table class="indent"> | |
<tr> | |
<td class="inline_code">BVSCALE_FASTEST</td> | |
<td>The fastest method of scaling available is used. This may include nearest neighbor. The value of | |
this enumeration is purposely 0, and is the default scale type. No implementation will return an error for | |
this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_FASTEST_NOT_NEAREST_NEIGHBOR</td> | |
<td>The fastest method of scaling available that is not nearest neighbor is used. This may include an alternative | |
point sample technique.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_FASTEST_POINT_SAMPLE</td> | |
<td>The fastest method of scaling using a point sample technique.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_FASTEST_INTERPOLATED</td> | |
<td>The fastest method of scaling using an interpolation technique.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_FASTEST_PHOTO</td> | |
<td>The fastest method of scaling appropriate for photographs is used. This may include nearest neighbor. | |
No implementation will return an error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_FASTEST_DRAWING</td> | |
<td>The fastest method of scaling appropriate for drawings is used. This may include nearest neighbor. | |
No implementation will return an error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_GOOD</td> | |
<td>A scaling technique is chosen that may be higher quality than the <span class="inline_code">BVSCALE_FASTEST</span> | |
choice. This may include nearest neighbor. No implementation will return an error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_GOOD_POINT_SAMPLE</td> | |
<td>A point sample scaling technique is chosen that may be higher quality than the <span class="inline_code">BVSCALE_FASTEST_POINT_SAMPLE</span> | |
choice. This may include nearest neighbor.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_GOOD_INTERPOLATED</td> | |
<td>An interpolated scaling technique is chosen that may be higher quality than the <span class="inline_code">BVSCALE_FASTEST_INTERPOLATED</span> | |
choice.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_GOOD_PHOTO</td> | |
<td>A scaling technique appropriate for photographs is chosen that may be higher quality than the | |
<span class="inline_code">BVSCALE_FASTEST_PHOTO</span> choice. This may include nearest neighbor. No | |
implementation will return an error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_GOOD_DRAWING</td> | |
<td>A scaling technique appropriate for drawings is chosen that may be higher quality than the | |
<span class="inline_code">BVSCALE_FASTEST_DRAWING</span> choice. This may include nearest neighbor. | |
No implementation will return an error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_BETTER</td> | |
<td>A scaling technique is chosen that may be higher quality than the <span class="inline_code">BVSCALE_GOOD</span> | |
choice. This may include nearest neighbor. No implementation will return an error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_BETTER_POINT_SAMPLE</td> | |
<td>A point sample scaling technique is chosen that may be higher quality than the <span class="inline_code">BVSCALE_GOOD_POINT_SAMPLE</span> | |
choice. This may include nearest neighbor.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_BETTER_INTERPOLATED</td> | |
<td>An interpolated scaling technique is chosen that may be higher quality than the <span class="inline_code">BVSCALE_GOOD_INTERPOLATED</span> | |
choice.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_BETTER_PHOTO</td> | |
<td>A scaling technique appropriate for photographs is chosen that may be higher quality than the | |
<span class="inline_code">BVSCALE_GOOD_PHOTO</span> choice. This may include nearest neighbor. No implementation | |
will return an error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_BETTER_DRAWING</td> | |
<td>A scaling technique appropriate for drawings is chosen that may be higher quality than the | |
<span class="inline_code">BVSCALE_GOOD_DRAWING</span> choice. This may include nearest neighbor. No | |
implementation will return an error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_BEST</td> | |
<td>The highest quality scaling technique is chosen. This may include nearest neighbor. No implementation | |
will return an error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_BEST_POINT_SAMPLE</td> | |
<td>The highest quality point sample technique is chosen.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_BEST_INTERPOLATED</td> | |
<td>The highest quality interpolated scaling technique is chosen.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_BEST_PHOTO</td> | |
<td>The highest quality scaling technique appropriate for photographs is chosen. This may include nearest | |
neighbor. No implementation will return an error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_BEST_DRAWING</td> | |
<td>The highest quality scaling technique appropriate for drawings is chosen. This may include nearest neighbor. | |
No implementation will return an error for this setting.</td> | |
</tr> | |
</table> | |
<br /> | |
<span class="inline_code">BVSCALEDEF_VENDOR_GENERAL</span> can be used to specify one of the shared explicit scale types. | |
At this point, only a limited number of explicit scale types are defined: <br /> | |
<br /> | |
<table class="indent"> | |
<tr> | |
<td class="inline_code">BVSCALE_NEAREST_NEIGHBOR</td> | |
<td>This is a point sample scaling technique where the resampled destination pixel is set to the value of the closest | |
source pixel.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_BILINEAR</td> | |
<td>This is an interpolated scaling technique where the resampled destination pixel is set to a value linearly interpolated | |
in two dimensions from the four closest source pixels.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_BICUBIC</td> | |
<td>This is an interpolated scaling technique where the resampled destination pixel is set to a value calculated | |
using cubic interpolation in two dimensions.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_3x3_TAP</td> | |
<td> </td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_5x5_TAP</td> | |
<td> </td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_7x7_TAP</td> | |
<td> </td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVSCALE_9x9_TAP</td> | |
<td> </td> | |
</tr> | |
</table> | |
<p>If the client wants to know the explicit type chosen by a given implementation, it can set <span class="inline_code"> | |
BVFLAG_SCALE_RETURN</span> in the <span class="inline_code"><a href="#flags">bvbltparams.flags</a></span> member, and the | |
explicit scale type is returned in the <span class="inline_code">scalemode</span> member.</p> | |
<p class="note">NOTE: Extending the <span class="inline_code">BVSCALEDEF_VENDOR_GENERAL</span> scale types or obtaining | |
a vendor ID can be accomplished by submitting a patch.</p> | |
<p class="Code_Header_2"><a name="dithermode">bvbltparams.dithermode</a></p> | |
<p class="code_block">enum bvdithermode dithermode; /* input/output */</p> | |
<p>This member allows the client to specify the type of dithering to be used, when the output format has fewer bits of depth | |
than the internal calculation. The enumeration begins with 8 bits indicating the vendor. The remaining bits | |
are defined by the vendor. <span class="inline_code">BVDITHERDEF_VENDOR_ALL</span> and <span class="inline_code">BVDITHERDEF_VENDOR_GENERAL</span> | |
are shared by all implementations.</p> | |
<p><span class="inline_code">BVDITHERDEF_VENDOR_ALL</span> can be used to specify an implicit dither type. This type | |
is converted to an explicit type by the implementation:</p> | |
<table class="indent"> | |
<tr> | |
<td class="inline_code">BVDITHER_FASTEST</td> | |
<td>The fastest method of dithering available is used. This may include no dithering (truncation). The | |
value of this enumeration is purposely 0, and is the default dither type. No implementation will return an | |
error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_FASTEST_ON</td> | |
<td>The fastest method of dithering available is used. This will not include no dithering.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_FASTEST_RANDOM</td> | |
<td>The fastest method of dithering using a random technique.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_FASTEST_ORDERED</td> | |
<td>The fastest method of dithering using an ordered diffusion technique.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_FASTEST_DIFFUSED</td> | |
<td>The fastest method of dithering using an error diffusion technique.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_FASTEST_PHOTO</td> | |
<td>The fastest method of dithering appropriate for photographs is used. This may include no dithering. | |
No implementation will return an error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_FASTEST_DRAWING</td> | |
<td>The fastest method of dithering appropriate for drawings is used. This may include no dithering. | |
No implementation will return an error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_GOOD</td> | |
<td>A dithering technique is chosen that may be higher quality than the <span class="inline_code">BVDITHER_FASTEST</span> | |
choice. This may include no dithering. No implementation will return an error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_GOOD_ON</td> | |
<td>Any dithering technique available is used. This will not include no dithering. This may be higher | |
quality than <span class="inline_code">BVDITHER_FASTEST_ON</span>.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_GOOD_RANDOM</td> | |
<td>A random dithering technique is chosen that may be higher quality than the <span class="inline_code">BVDITHER_FASTEST_RANDOM</span> | |
choice.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_GOOD_ORDERED</td> | |
<td>An ordered dithering technique is chosen that may be higher quality than the <span class="inline_code">BVDITHER_FASTEST_ORDERED</span> | |
choice.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_GOOD_DIFFUSED</td> | |
<td>A diffused dithering technique is chosen that may be higher quality than the <span class="inline_code">BVDITHER_FASTEST_DIFFUSED</span> | |
choice.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_GOOD_PHOTO</td> | |
<td>A dithering technique appropriate for photographs is chosen that may be higher quality than the | |
<span class="inline_code">BVDITHER_FASTEST_PHOTO</span> choice. This may include no dithering. No implementation | |
will return an error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_GOOD_DRAWING</td> | |
<td>A dithering technique appropriate for drawings is chosen that may be higher quality than the | |
<span class="inline_code">BVDITHER_FASTEST_DRAWING</span> choice. This may include no dithering. No | |
implementation will return an error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_BETTER</td> | |
<td>A dithering technique is chosen that may be higher quality than the <span class="inline_code">BVDITHER_GOOD</span> | |
choice. This may include no dithering. No implementation will return an error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_BETTER_ON</td> | |
<td>Any dithering technique available is used. This will not include no dithering. This may be higher | |
quality than <span class="inline_code">BVDITHER_GOOD_ON</span>.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_BETTER_RANDOM</td> | |
<td>A random dithering technique is chosen that may be higher quality than the <span class="inline_code">BVDITHER_GOOD_RANDOM</span> | |
choice.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_BETTER_ORDERED</td> | |
<td>An ordered dithering technique is chosen that may be higher quality than the <span class="inline_code">BVDITHER_GOOD_ORDERED</span> | |
choice.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_BETTER_DIFFUSED</td> | |
<td>A diffused dithering technique is chosen that may be higher quality than the <span class="inline_code">BVDITHER_GOOD_DIFFUSED</span> | |
choice.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_BETTER_PHOTO</td> | |
<td>A scaling technique appropriate for photographs is chosen that may be higher quality than the | |
<span class="inline_code">BVSCALE_GOOD_PHOTO</span> choice. No implementation will return an error for this | |
setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_BETTER_DRAWING</td> | |
<td>A scaling technique appropriate for drawings is chosen that may be higher quality than the | |
<span class="inline_code">BVSCALE_GOOD_DRAWING</span> choice. No implementation will return an error for this | |
setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_BEST</td> | |
<td>The highest quality dithering technique is chosen. This may include no dithering. No implementation | |
will return an error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_BEST_ON</td> | |
<td>Any dithering technique available is used. This will not include no dithering. This may be higher | |
quality than <span class="inline_code">BVDITHER_BEST_ON</span>.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_BEST_RANDOM</td> | |
<td>The highest quality random dithering technique is chosen.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_BEST_ORDERED</td> | |
<td>The highest quality ordered dithering technique is chosen.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_BEST_DIFFUSED</td> | |
<td>The highest quality diffused dithering technique is chosen.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_BEST_PHOTO</td> | |
<td>The highest quality dithering technique appropriate for photographs is chosen. This may include no dithering. | |
No implementation will return an error for this setting.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_BEST_DRAWING</td> | |
<td>The highest quality dithering technique appropriate for drawings is chosen. This may include no dithering. | |
No implementation will return an error for this setting.</td> | |
</tr> | |
</table> | |
<br /> | |
<span class="inline_code">BVDITHERDEF_VENDOR_GENERAL</span> can be used to specify one of the shared explicit dithering | |
types. At this point, only a limited number of explicit dither types are defined:<br /> | |
<br /> | |
<table class="indent"> | |
<tr> | |
<td class="inline_code">BVDITHER_NONE</td> | |
<td>No dithering is performed. Internal pixel component values are truncated to the destination component | |
bit depth.</td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_ORDERED_2x2</td> | |
<td> </td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_ORDERED_4x4</td> | |
<td> </td> | |
</tr> | |
<tr> | |
<td class="inline_code">BVDITHER_ORDERED_2x2_4x4</td> | |
<td>2x2 ordered dither is used for components with the lowest bit reduction. 4x4 ordered dither is used for | |
the components with the highest bit reduction. (E.g. RGB24 to RGB565 will use 2x2 ordered dither for the green | |
component and 4x4 ordered dither for the red and blue components.)</td> | |
</tr> | |
</table> | |
<p>If the client wants to know the explicit type chosen by a given implementation, it can set <span class="inline_code"> | |
BVFLAG_DITHER_RETURN</span> in the <span class="inline_code"><a href="#flags">bvbltparams.flags</a></span> member, and the | |
explicit scale type is returned in the <span class="inline_code">dithermode</span> member.</p> | |
<p class="note">NOTE: Extending the <span class="inline_code">BVDITHERDEF_VENDOR_GENERAL</span> scale types or obtaining | |
a vendor ID can be accomplished by submitting a patch.</p> | |
<p class="Code_Header_2"><a name="dstdesc">bvbltparams.dstdesc</a></p> | |
<p class="code_block"><a href="#bvbuffdesc">struct bvbuffdesc</a> *dstdesc;</p> | |
<p><span class="inline_code">dstdesc</span> is used to specify the destination buffer. If the buffer has not been | |
mapped with a call to <span class="inline_code"><a href="#bv_map">bv_map()</a></span>, <span class="inline_code"> | |
<a href="#bv_blt">bv_blt()</a></span> will map the buffer as necessary to perform the BLT and then unmap afterwards. | |
See <span class="inline_code"><a href="#bvbuffdesc">bvbuffdesc</a></span> for details.</p> | |
<p class="Code_Header_2"><a name="dstgeom">bvbltparams.dstgeom</a></p> | |
<p class="code_block"><a href="#bvsurfgeom">struct bvsurfgeom</a> *dstgeom;</p> | |
<p><span class="inline_code">dstgeom</span> is used to specify the geometry of the surface contained in the destination | |
buffer. See <span class="inline_code"><a href="#bvsurfgeom">bvsurfgeom</a></span> for details.</p> | |
<p class="Code_Header_2"><a name="dstrect">bvbltparams.dstrect</a></p> | |
<p class="code_block"><a href="#bvrect">struct bvrect</a> dstrect;</p> | |
<p><span class="inline_code">dstrect</span> is used to specify the destination rectangle to receive the BLT. This | |
rectangle is clipped by <span class="inline_code"><a href="#cliprect">bvbltparams.cliprect</a></span> when | |
<span class="inline_code"><a href="#BVFLAG_CLIP">BVFLAG_CLIP</a></span> is set in the <span class="inline_code"> | |
<a href="#flags">bvbltparams.flags</a></span> member.</p> | |
<p class="Code_Header_2">bvbltparams.<a name="src1.desc">src1</a>/<a name="src2.desc">src2</a>/<a name="mask.desc">mask.desc</a></p> | |
<p class="code_block"><a href="#bvbuffdesc">struct bvbuffdesc</a> *src1.desc;<br /> | |
<a href="#bvbuffdesc">struct bvbuffdesc</a> *src2.desc;<br /> | |
<a href="#bvbuffdesc">struct bvbuffdesc</a> *mask.desc;</p> | |
<p>These members are used to identify the buffer for the source1, source2, and mask surfaces when the associated | |
<span class="inline_code">BVFLAG_TILE_*</span> |