Subject: [Thuban-list] [Patch] Improved hsv ramps patch

From: "Daniel Calvelo Aros" <[email-masked]>
Date: Fri, 20 Feb 2004 17:55:18 -0500

Hi all.

Following comments from BH and the new style guide, here is an improved
(commented, styled, simplified) version of the HSV ramps patch.

Please give it a try and advise. To be a proper patch, it needs: tests,
Changelog entry.

It patches CVS from 18/02 cleanly, although it's a diff against CVS from 22/01.

Daniel.

-- Daniel Calvelo Aros
-- Dirección General de Información Agraria
-- Ministerio de Agricultura del Perú
-- (51-1)424-9001

---

From: Bernhard Herzog <[email-masked]>
Date: Mon, 23 Feb 2004 21:20:29 +0100

> (commented, styled, simplified) version of the HSV ramps patch.

Thanks.  Much better now.

> Please give it a try and advise. To be a proper patch, it needs: tests,

I think we can check this in once we have tests.  I would especially
like to see tests for interpolate_hsv because it has quite a few special
cases.

Another thing that we might want to fix, but this can be done after the
hsv code has been checked in, is the way Transparent is interpolated
with non-transparent color.

As it's currently implemented in CVS (and inherited from the that in the
interpolate_rgb and interpolate_hsv functions in the patch) is wrong,
imo.  For example. interpolate_rgb(Color(1, 1, 1), Transparent, 0)
yields black and not as one would expect, white.  However, I'm not even
sure those functions should even allow interpolation of Transparent with
non-transparent colors.  If Thuban could handle translucent shapes that
might be useful but currently it doesn't so that kind of interpolation
cannot really be done in a sensible way.

At the moment, I'd say that the interpolation functions should simply
assume that the color parameters are normal RGB colors and raise
exceptions when that assumption doesn't hold.  This could either be done
implicitly when trying to access the red, green and blue attributes or
more explicitly by checking whether either of the color parameters is
Transparent and raise e.g. TypeError.  Handling of Transparent for class
generation would then have to be done by the CustomRamp class.

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                http://sketch.sourceforge.net/
Thuban                                  http://thuban.intevation.org/

---

From: "Daniel Calvelo Aros" <[email-masked]>
Date: Thu, 26 Feb 2004 19:05:35 -0500

On Mon, 23 Feb 2004 21:20:29 +0100, Bernhard Herzog wrote
> like to see tests for interpolate_hsv because it has quite a few special

Right. It's coming along.

> As it's currently implemented in CVS (and inherited from the that in 
> the interpolate_rgb and interpolate_hsv functions in the patch) is 
> wrong, imo.  For example. interpolate_rgb(Color(1, 1, 1),
>  Transparent, 0) yields black and not as one would expect, white.  
> However, I'm not even sure those functions should even allow 
> interpolation of Transparent with non-transparent colors.  If Thuban 
> could handle translucent shapes that might be useful but currently 
> it doesn't so that kind of interpolation cannot really be done in a 
> sensible way.
> 
> implicitly when trying to access the red, green and blue attributes 
> or more explicitly by checking whether either of the color 
> parameters is Transparent and raise e.g. TypeError.  Handling of 
> Transparent for class generation would then have to be done by the 
> CustomRamp class.

How hard would be to switch the default renderer to a wxGL canvas? Maybe it's
time to begin that work...

Daniel.

-- Daniel Calvelo Aros