What to do about KColor?
mw_triad at users.sourceforge.net
Sun May 27 06:47:12 BST 2007
Thomas Zander wrote:
> Now you bring back the
> original proposal, without any change that I can see!
I proposed three static methods in a namespace, plus some *private*
implementation details. Unless I am mistaken that is a significant
change. (In case it is cause for confusion, please note that the code in
playground has /not/ been changed yet to reflect this.)
Let me try to explain this succinctly one more time... There are two
suggestions currently on the table for a blend function in kdelibs:
QColor blend(QColor, QColor, QPainter::CompositionMode mode =
Uses an enum that exists in Qt.
Incompatible with Pigment. We have no control over the implementation.
At best we can write fast implementations of particular modes on an
ad-hoc basis, but because we do not control the enum, we *must* rely on
an extremely inefficient fallback implementation using a QImage (which,
while I haven't checked, probably has to allocate on the heap). Calling
the function requires three lines of code including declaration of a
QColor blend(QColor, QColor, double amount = 0.5,
BlendMode mode = BlendNormal, ColorSpace space = Rgb);
Easily called in the middle of code. Fully extensible in KDE, not
reliant on TT. Conforms closely to KoColor, both making that a viable
option for implementation and reducing the likelihood of adding similar
methods in the future. Because KDE controls it, a (high performance)
pure math implementation using only stack allocation is viable.
Has more arguments. Doesn't use Qt.
As a result of the difficulty of use and performance concerns of #1, I
cannot see that #1 provides enough benefit to justify converting
existing homegrown implementations to this. Which means #1 fails to meet
kdelibs inclusion criteria.
(sorry, .sig file is on the other computer)
More information about the kde-core-devel