On Friday, 1 Jun 2001, David Monniaux wrote:
I would like to know the precise functions that handle the shrinking of
the image for display. I would like to code them in MMX.
What leads you to suspect that scaling the image for display is a
bottleneck?
Last time I looked, it was much higher-level stuff that was making the
Gimp slow. Eg, repainting the canvas several times when once would
have been enough.
The next culprit was the functions involved in applying paint strokes,
merging in the existing paint with the new paint. But these have
already been tuned quite a bit (by Jay Cox, if I remember correctly?)
So, rewriting the display code in MMX is pretty pointless if you're
looking to speed up the Gimp. If you're doing it to educate yourself
about MMX it might be interesting, I grant you.
An MMX rewrite also has numerous disadvantages. You'd still need to
keep a C version lying around so that non-Intel platforms can work.
So that means you now have two pieces of code floating around which
should do the same thing, and need to be kept in step with each other.
This is a maintenance nightmare. Now instead of needing to know just
C, maintainers need to know both C and Intel MMX assembly. This
instantly reduces the number of people who can help fix bugs. Also,
bug reports are complicated by the fact that now display-related bugs
need to say which architecture it was on. Given the typically low
quality of bug reports (eg it shows me a garbled image) even just
finding out the architecture is quite hard.
Re-writing the C to use a better algorithm, or tuning it to place
variable in better locations on the stack, would be a much preferable
solution. That way the algorithm is still just C. For example, the
algorithm currently uses an integer fixed-point approximation to keep
track of the render error. Originally I coded it up using floating
point, but it was slightly slower in the subsequent testing I did, so
I re-coded it in fixed point. I tested on a Pentium 133 and an Alpha
21064, and both came ahead using the integer fixed-point algorithm.
Maybe that trade off is different with today's common CPUs, I haven't
looked into it recently.
I suggest you read The Practice of Programming by Brian W. Kernighan,
Rob Pike. Addison-Wesley, 1999 ISBN: 020161586X.
In particular, I'm thinking of the chapter on performance tuning.
In summary: find out where the bottleneck actually is (by profiling)
before jumping in and micro-optimising the wrong thing.
To answer your original question, the display code is in
app/image_render.c Note that not all the render functions were
reachable last time I looked at the code in detail. This is in 1.2.1.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
