[vtk-developers] Manual conversion of some Tcl to Python tests.

Jeff Baumes jeff.baumes at kitware.com
Mon Sep 3 08:31:05 EDT 2012


On Sun, Sep 2, 2012 at 6:43 PM, Andrew Maclean
<andrew.amaclean at gmail.com> wrote:
> 1) Associate color names with values.
> 2) Be easily searchable.
> 3) Some of you also touched on this:
>    Have methods like:
>        void SetColor( std::string name, double * rgba)
>        void SetColorDouble( std::string name, double r, double g,
> double b, double a = 1.0)
>        void SetColor ( std::string nane, unsigned char r, unsigned
> char g, unsigned char b, unsigned char a = 255)
>
>       double * GetColorDouble( std::string name )
>       unsigned char* GetColor( std::string name )
>       void GetColorDouble( std::string name, double & r, double & g,
> double & b, double & a)
>       void GetColor ( std::string name, unsigned char & r, unsigned
> char & g, unsigned char & b, unsigned char & a)

All this API looks good to me, and would indeed be the path of least
resistance and provide the most utility to existing VTK users. I this
we could also have methods for vtkColor4ub, vtkColor4d, but those who
care about such conveniences (i.e. likely not you) could add those at
a later time.

> 6) The other question is do we use an unsigned int to store the
> hexadecimal representation?
>     My feeling is no because it limits future expansion and
> bit-shifting/masking needs to take into account big/little endian
> characteristics.
>     So I would prefer storing as an unsigned char vector.
>    This raises a question regarding storage in that should we just use
> unsigned int instead of unsigned char to cater for future expansion?

Really, storage does not matter long-term, because it can always be
changed without affecting API. The only caveat is that if you are
returning double* and unsigned char*, that means vtkNamedColors needs
to have some persistent storage for those values. Either you have
internal storage for all colors as both double and unsigned char, or
on the fly you put it in a "temp" variable that holds the value of the
last returned color. I'd rather have the first implemented if you go
with functions that return pointers, even with all the extra storage,
because this bug that other VTK code allows with the second option is
very odd. vtkPoints.h even tells you to not use GetPoint() for this
reason. So I'd rather not add new API which will end up having
documentation that says "don't use this".

double* p1 = pts->GetPoint(0);
double* p2 = pts->GetPoint(1);
// Uh, oh. Now p1's contents are the same as p2.

If you want methods with return values, this brings us back to the
great things about the vtkColor classes, since they would safely allow
the compact inline calls that you wanted to have in your use case.

> In conclusion, I am happy to set up a topic and have a go at creating
> a class to encapsulate the above points as an initial starting point.
> Then we can refine it.

Yes, please just go for it. You won't make everyone happy but real
code that is ok is much better than grand plans with no code.

Jeff



More information about the vtk-developers mailing list