So the comment I propose mixing what you said with my understanding:

I'm an abstract class which introduce a filter between a drawing request and the final output, handled by #mapColor:

For each potential pixel operation like:��source -> op -> output
it introducing a color mapping stage:��source -> op -> mapping -> output

Then #mapColor: can be redefined in subclasses to implement more specific behavior. For example:

- ShadowDrawingCanvas will replace the rendered color with the color of shadow (if not transparent).
- AlphaBlendingCanvas will add or intensify alpha of rendered color.

For an easy to understand example see ��#drawPolygon:color:borderWidth:borderColor:

ShadowDrawingCanvas:

see ColorMappingCanvas comment.

AlphaBlendingCanvas:

Laurent.

On Mon, Feb 14, 2011 at 7:57 PM, Igor Stasenko <siguctua@gmail.com> wrote:

On 14 February 2011 18:45, laurent laffont <laurent.laffont@gmail.com> wrote:
> Today: ��ColorMappingCanvas
>

As far as i understood, this class is abstract, and its subclasses
implement more specific behavior
- shadow
- semitransparency mapping


The idea of is kind of canvas is to modify/filter the final output in
rendering pipe..
i.e., for each potential pixel operation like:

source -> op -> output

it introducing a color mapping stage:

source -> op -> mapping -> output


So, then for instance you could make a subclass which could turn all
colors to be grayscale (disregarding that initial input was in
colors).

in fact i think this guy took wrong direction. It is much more
effective to let the canvas to draw whatever it wants to some
backup/temporary surface, and once it done, simply blit + color-map
result to destination form using one, single strike.


--
Best regards,
Igor Stasenko AKA sig.