This may have something to do with the performance:
gcc-3.4 (GCC) 3.4.2 (Debian 3.4.2-3)
This compiler does alias analysis and whole-file optimization.
If that does the job for you, then don't worry. Most users
will be getting binaries compiled with gcc 3.4 or later.
For the Windows build, ensure that the fast math options
are enabled. (using the x86 transcedental math instructions)
If alias analysis is an option, enable that too.
There are plenty of opportunities for hand-optimizing the
code if compiler adjustments don't do the job. I didn't
bother, because a bone-headed implementation was easier
to develop and plenty fast on my system. Some ideas are:
a. reduce the size of the multichan struct
b. re-use original sRGB data for unmodified pixels
c. use a look-up table for sRGB to L,u,v
d. [painful and inaccurate] interpolate for L,u,v to sRGB
It would be great if you could run a line-by-line profiler
on the code to see where the time is going. Try using
oprofile and kcachegrind to find where cache misses happen.
(this is where the --playback option would be great)
Windows profiler output might be helpful too. Surely there
are some suitable tools... maybe Intel provides some?
_______________________________________________
Tuxpaint-dev mailing list
[EMAIL PROTECTED]
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
