Re: [Gimp-developer] gimp-developer-list Digest, Vol 26, Issue 10

Hi DeVont, thanks for your suggestions & interest in contribution.

I'm not really a GIMP developer and am definitely not familiar with the
codebase, but I'm deeply familiar with software engineering/ re-engineering
& I'll just give you a few comments on first principles.

1. gimp/libgimpmath/gimpmathtypes.h (file in

This file declares math structures that gimp uses like vectors and
matrices. The GimpMatrix structure come in 2X2, 3X3 and even 4X4 versions.
Each matrix is a 2Dimensional gdouble array with the appropriate amount of
elements to span the NXN matrix.I believe this data structure is used for
computation during image editing. There are functions handling
comparisons, identities, transformations, rotations, translations and
various other matrix operations.

Possible changes: I believe the declaration of 3 special kinds of gimp
matrices can be generalized to a struct (or class) that holds and defines
an NXN matrix.

Generalizing these structures, would almost certainly make them slower.
While in peripheral areas that might be fine, I do not think GIMP users
wish to lose performance on matrix-based image transformations.

Neither am I aware that there could ever be a need for matrices larger than

So, I probably recommend against pursuing #1.

2. gimp/app/core/gimpcontainer.h
This class contains a data structure that is used to store different
things about the
various objects in gimp. It works hand and hand with the GimpObject class.
This class uses what I believe to be some form of tree or heap structure.
class refers to add, remove, reorder, and getChild functions that are
across the class. The gimp.h code uses the GimpContainer class pointers
for everything
from fonts, to documents, to displays. As this data structure is used with
GimpObject (which controls a large amount of functionality in gimp) and is
heavily referenced in the gimp.h file, optimizing this class could go a
long way in
optimizing the code.

This area is probably more productive for investigation. You will need to
take some measurements/ benchmarks, to verify whether your changes are
delivering an actual performance improvement -- and by how much.

If you document the number of calls into this data structure/site, measure
performance beforehand, trial various changes, measure & document
performance from each version, write the results up formally and submit
code (if any) you will have completed your assignment fully.

I am not assuming that you will be able to improve performance, this may be
quite possible but even measuring & investigating thoroughly and coming to
the well-supported conclusion that you can't, would be a very competent
completion of your assignment.

If we decrease the amount of time to ?reorder? the tree, then we decrease
the amount of time
several other objects take to be initialized and added to the tree.

Well, it sounds quite plausible!  But only the measurements can tell.

3. gimp/libgimpmath/gimpvector.h(c)
The GimpVector data structure keeps track of axis orientations and
I believe this is used in the various drawing tools. I also believe the
automated shapes functions may use it for drawing polygons. The vector
structure is a structure that holds four gdouble variables that are
separately declared (gdouble x, y, z, w for the 4axis vector for example).
There are three versions of the gimp vector: 2axis, 3axis, and 4axis. A
potential change to
GimpVector could be altering the way that it is stored like we plan to
change the GimpMatrix. This means making a streamlined generalized vector
that can be of
dimension N.

I didn't like the GimpMatrix idea, due to reduced efficiency of
very-heavily used code. I expect the GimpVector may also be quite heavily
used -- perhaps less so than GimpMatrix, but I would have to be convinced
it was not performance-critical.

"Unrolled loops" -- and thus separate size-specific implementations, as per
the existing code -- are the best design choice for performance-critical

Implementing a variable-length vector/list will, I expect, be vastly slower
than using a fixed-size struct or array. Structs and arrays are much more
efficient to allocate & de-reference.. Perhaps comparing such codes on a
testbed might give you a better idea/assessment of the potential relative


It's great that your group is interested & willing to challenge yourself,
by taking a look at some serious large-scale software.

I think #2 (GimpContainer/ the heap) sounds like the most plausible area
for investigation & optimization. Make sure you measure & benchmark in a
reliable way (warm-up first, # of iterations, etc) -- you may need to write
some scripts or support code to enable this.

Be sure to write up all your initial measurements, different approaches,
results & conclusions.

Good luck!

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]