CKMY craziness...

[Boudewijn Rempt]

On Wednesday 17 November 2004 20:32, Saem Ghani wrote:
> I've been hacking away at the code, trying to figure out why CKMY is
> borked. I'm still basically no where with it, but I think I have some idea
> where some of the issues might be comming from.  But they're hard to track
> down, thanks to QUANTUM*.  I'm fairly certain that there is spill over and
> the wrong values are being effected.

Quite probably; another source of problems might be my old caching conversion 
table.


> So I'm voting for a refactoring of QUANTUM* to std::vector<QUANTUM>.  I'm
> going for the STL version instead of QVector, simply because the STL
> version supports arithmetic and a few other features which will reduce the
> amount of work for this particularly refactoring job. 

Moving to vector is not something simple to do: Krita uses those pointers to 
quantums everywhere. There was some discussion about using vectors vs. using 
pointers to quantums some time ago; the more-or-less decision was to go on 
using pointers to bytes, where in the future a single channel could occupy 
one or more bytes and would be interpreted by the colour channel.

Casper Boemann was going to experiment with that idea and I setup a cvs branch 
for him, but I haven't heard anything about it since then. 

If you want to convert all use of QUANTUM* to vector<QUANTUM> you need to take 
the following into consideration:

* Do your vectors contain just the channels for one pixel, or do they contain 
the channels for all pixels one might feed to a colour strategy.
* How does this integrated with the iterators Cyrille is working on?
* Can you still efficiently copy whole blocks of pixels, or are we going to 
always work with one pixel at a time?

And probably lots more things; I'm not against using vectors instead of 
pointers (as I said in previous discussions -- I dislike pointers with all 
the vehemence of a Python hacker), but if we use vectors I think we should 
take the opportunity to get rid of the QUANTUM definition and move to a 
situation where a channel can be one or more bytes, with the colour strategy 
interpreting the bytes as integers, bytes or even floats.

In short -- this calls for a moment of reflection, design & a patch we can 
discuss :-).

> Additionally, I was 
> really surprised at the lack of refactoring features in KDevelop, but
> refactoring in C++ is a PAIN!

As far as I know there is no good C++ refactoring tool available (there's one 
that integrates with (X)Emacs, but its commercial in the first place, and not 
that powerful in the second place). Not even Eclipse has decent refactoring 
support. I believe that refactoring C++ is considered a hard problem...

-- 
Boudewijn Rempt | "Geef mij maar zuurtjes."
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20041117/c5c798b5/attachment.pgp