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

[Thomas W <twhitmore nz gmail com>]

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
> question:gimp/libgimpmath/gimpmatrix.h(c))
>
> 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
4x4.

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.
The
> class refers to add, remove, reorder, and getChild functions that are
defined
> 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
lengths.
> 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
data
> 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
code.

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
performance?

IN CONCLUSION:

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!