<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE TIP SYSTEM "http://www.tcl.tk/cgi-bin/tct/tip/tipxml.dtd">
<!-- Converted at Sun May 19 09:55:17 GMT 2013 -->
<!-- TIP AutoGenerator - written by Donal K. Fellows -->

<TIP number='98'>
<header><title>Adding Transparency Compositing Rules to Photo Images</title><author address="mailto:fellowsd@cs.man.ac.uk">Donal K. Fellows</author><status type='project' state='final' tclversion="8.4" vote='after'>$Revision: 1.5 $</status><history></history><created day='9' month='jun' year='2001' /></header>
<abstract>This TIP adds compositing rules to Tk&apos;s photo images to give programmers better control over what happens when two transparent images are combined. This TIP also allows for several frames of an animated GIF file to be correctly displayed in an image even when the transparent area is not constant.</abstract>
<body><section title="Rationale">
<para>This is a TIP that is inspired by the tkchat application in Tcllib, and in particular by the image used to represent the LOL smiley. The problem with this image is that its transparent area changes over time, and this is caused by the fact that <emph style="italic">Tk_PhotoPutBlock()</emph> only allows one way of compositing a block with an image; it behaves as if the data being added was on a sheet of cel (the material used to make hand-drawn animated cartoons) allowing for sophisticated layering effects. Unfortunately, for many applications (and animated GIF images are definitely among these) this sophistication works against us. In a GIF image, transparency is treated not as extra information that is added to each pixel&apos;s colour, but rather as a special colour; a pixel cannot be, for example, red and transparent at the same time. Support for this requires a different (and indeed simpler) kind of compositing rule. And of course, once you have such a facility in the underlying C code, it should be exposed to scripts.</para>
<para>There are other kinds of compositing rule (for example, acting like the added block is placed under the image, and many others) but this TIP does not propose adding anything other than a way to chose between the current behaviour and the behaviour required for supporting GIF animation, in the belief that those two compositing rules are the ones most useful to programmers, and that once the general facility is there, the other rules will be relatively easy to add in the future.</para>
</section>
<section title="Specification">
<para>This TIP adds a <emph style="italic">compositingRule</emph> argument to <emph style="italic">Tk_PhotoPutBlock</emph> (and <emph style="italic">Tk_PhotoPutZoomedBlock</emph>) to allow selection between the current behaviour (overlaying) and the other one I wish to support (setting/overriding.) The permitted values of this argument will be <emph style="italic">TK_PHOTO_COMPOSITE_OVERLAY</emph> (the currently implemented behaviour) and <emph style="italic">TK_PHOTO_COMPOSITE_SET</emph> (the behaviour required to support GIF file animation.)</para>
<para>At the Tcl level, when copying from one image to another (the other photo image subcommands do not currently support transparency at all) the <emph style="italic">photo get</emph> will take an extra option <emph style="italic">-compositingrule</emph> to allow selection of the compositing rule. The permitted values of this option will be <emph style="italic">overlay</emph> and <emph style="italic">set</emph> by analogy with the values described above.</para>
</section>
<section title="Implementation Notes">
<para>Proposed implementation patch: <url ref="https://sourceforge.net/tracker/index.php?func=detail&amp;aid=566765&amp;group_id=12997&amp;atid=312997"/></para>
<para>The proposed implementation of this TIP naturally includes backward-compatibility functions that allow pre-compiled extensions to continue to operate without recompilation (provided they use Stubs for linking.) Furthermore, extension authors can also define the symbol <emph style="italic">USE_COMPOSITELESS_PHOTO_PUT_BLOCK</emph> when compiling and have source-level compatibility with the old functions.</para>
<para>The proposed implementation also creates <emph style="italic">TkSubtractRegion</emph> as a new internal function; it is the analogue of <emph style="italic">XSubtractRegion</emph> as <emph style="italic">TkIntersectRegion</emph> is the analogue of <emph style="italic">XIntersectRegion</emph>. It might be useful to other parts of the core that manipulate regions.</para>
<para>Both the PPM and GIF file readers use the <emph style="italic">set</emph> compositing rule, PPM because the format does not support transparency (and <emph style="italic">set</emph> should at least theoretically be faster) and GIF because it is required semantically. Other image formats are not required to do this, of course. The <emph style="italic">$img put $data</emph> photo image subcommand uses <emph style="italic">set</emph> compositing because it does not support transparency.</para>
</section>
<section title="Copyright">
<para>This document is placed in the public domain.</para>
</section>
</body></TIP>
