Re: [Gimp-developer] I am hoping to contribute to GIMP. I have some ideas, but I want input if possible.


On Tue, Nov 12, 2013 at 5:30 PM, DeVonte Applewhite <dapplewh nd edu> wrote:
Hello all,

I am in a Data Structures class which has a final project. This project
requires students to fix bugs, improve preexisting data structures, or add
extra features to an open source project that has an active community. My
group chose GIMP.

Nice choice! :-)

I have some ideas about changing data structures in hopes
of generalizing some implementations, improving execution speed and
reducing the amount of code needed to complete implementation of the .h

Here are 3 of our ideas. If you could give input (feasibility, faults in
our plan of action, predicted improvements upon success of these ideas,
suggestions) on any or all of our ideas, that would be greatly appreciated.

Well I won't comment all the ideas in detail, and my guess is there
are few chances others will either, because that would take quite a
time! We don't know the whole code by heart, so to understand what you
speak about, we would have to read the code you speak about carefully;
and even so, when I see the kind of changes you propose, I'm not sure
we will just say that's good ideas out of our head by just reading
code. You seem to be proposing mostly API change or code optimization.
But as often in optimization, it starts with gut feeling (except when
dealing with obvious bad designs), and some algorithm cost
computation, but in the end only real testing will really tell.
So if you really feel that's the way to go, you can still implement
it, test it, and if it appears to be a lot better than previously,
then you won. Propose a patch with some benchmark results and someone
will have at look at this.

Now this said, I really wonder if API changes or algorithm
optimizations are the best way to start in OpenSource contribution. A
codebase like GIMP is huge and very complicated and you want to start
with base classes. First of all, classes which are used in a lot of
places may also break many different pieces of code if you change
things (API or algorithm) there. So that implies a lot of regression
testing, which means a lot of time.
Second, even though base classes are indeed used in a lot of places,
and optimizations are always good, well it is not that obvious that
the optimization will get that tremendous speed improvements compared
to all the other things done along the way.
Last, API change just for the sake of API change, I'm not sure that's
the best idea. We will usually do something because we actually want
to use it and see it will make actual code better. I'm not sure if API
change which "may" make some future code better is a good way to do

I would think an easier way to start contributing is to fix bugs. We
have quite a lot of bugs in our bug tracker waiting to be fixed. Just
pick some of them, and fix them. Then you are sure this will be wanted
code, and there is no "maybe" or incertitude. Also that's a lot
easier, though very visible.

But if you're sure your propositions are worth it, the best is to do
the changes and propose patches. :-) As I said, I haven't looked at
them in details. Maybe that's great ideas, no idea. I know some
contributors start with base consolidations, not fixes. It happens.
In any case, have fun with GIMP,


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. We
could make it as general as possible to save the amount of code necessary
to complete the tasks. This also eliminates two extra structs in the .h
file. We could also change the structure that holds the matrix elements.
One way could be by making a nested linked list to emulate an NXN matrix.
This way, we keep everything in memory and not on the stack. If necessary,
we could even overload the [] operator to make the functionality act like
an array. We could also use the std::vector<T> data structures included in
the <vector> library to allow for pushing and popping of matrix data
structures to make them dynamic and or more fail-safe.

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.
class uses what I believe to be some form of tree or heap structure. The
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
referenced in the gimp.h file, optimizing this class could go a long way in
optimizing the code. 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
added to the tree.

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. Storing the axes
in an std::vector<T> or a linked list of size N could generalize the vector
to be declared of any arbitrary number of axes. Another thing we could do
is overload the operators between vectors such as addition, subtraction and
multiplication. Currently they are of the form, GimpVector add(GimpVector
&gv1,GimpVector &gv2). We could make it as easy as adding two vectors with
the + operator to make the code more readable. We can also overload various
other operators to make the GimpVector data structure more flexible and
powerful. This hopefully will increase the functionality and potency of the
GimpVector data structures and make them more accessible to new Gimp
developers in the future.
gimp-developer-list mailing list
List address:    gimp-developer-list gnome org
List membership:

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