RSS/Atom feed Twitter
Site is read-only, email is disabled

I am hoping to contribute to GIMP. I have some ideas, but I want input if possible.

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

5 of 8 messages available
Toggle history

Please log in to manage your subscriptions.

I am hoping to contribute to GIMP. I have some ideas, but I want input if possible. DeVonte Applewhite 12 Nov 04:30
  I am hoping to contribute to GIMP. I have some ideas, but I want input if possible. Jehan Pagès 12 Nov 09:39
   CAK_Oy+2dtbHW2hFzUZDtSyE=pG... 17 Nov 23:39
    I am hoping to contribute to GIMP. I have some ideas, but I want input if possible. Jehan Pagès 17 Nov 23:38
     CAK_Oy+3-d5MfoM9HoBiT4G3xkn... 09 Dec 03:57
      CAK_Oy+05UTp+wX1ddJAq=ZC2y0... 09 Dec 03:57
       I am hoping to contribute to GIMP. I have some ideas, but I want input if possible. Jehan Pagès 09 Dec 03:56
  I am hoping to contribute to GIMP. I have some ideas, but I want input if possible. scl 12 Nov 19:17
DeVonte Applewhite
2013-11-12 04:30:24 UTC (over 10 years ago)

I am hoping to contribute to GIMP. I have some ideas, but I want input if possible.

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. 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 files.

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.

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. 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 data structures included in the 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. 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. 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.

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 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.

Jehan Pagès
2013-11-12 09:39:19 UTC (over 10 years ago)

I am hoping to contribute to GIMP. I have some ideas, but I want input if possible.

Hi,

On Tue, Nov 12, 2013 at 5:30 PM, DeVonte Applewhite 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 files.

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 it.

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,

Jehan

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. 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 data structures included in the 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. 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. 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.

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 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: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

scl
2013-11-12 19:17:25 UTC (over 10 years ago)

I am hoping to contribute to GIMP. I have some ideas, but I want input if possible.

Hi,

thank you for your offer. Of course it sounds interesting to find somebody who likes to contribute and - from your side - to find an interesting open source project to support with your abilities. I agree with most of what Jehan already said. Let me add that GIMP is not written in C++, but C. To estimate the impact of your changes, it's surely better to know clearly (rather than believe) what the data structures you've planned to optimize are for and where and why they are used.

Kind regards and happy GIMPing,

Sven

Jehan Pagès
2013-11-17 23:38:22 UTC (over 10 years ago)

I am hoping to contribute to GIMP. I have some ideas, but I want input if possible.

Hi,

On Mon, Nov 18, 2013 at 12:09 PM, DeVonte Applewhite wrote:

Thank you for your response. We have used your input to clarify our direction on this project. What do you think of this. 1. We will try to make a c++ implementation of gimpvector where we overload operators and try to string the executable together so that it compiles.

As Sven also answered on the mailing list, GIMP is written in C, not C++. And even though it may happen that some components may be written in C++ if really it helped somehow (for instance when using some third party library in C++ which is the best at what it does), I'm pretty sure our maintainer won't accept any base class in C++, especially for no reason.

Now if that's just for the fun of the experiment and the sake of your class project, go ahead. :-) But don't have your expectations too high, because such code may never make it upstream.

2. We will try to make a c++ implementation of gimpmatrix where we overload operators and try to string the executable together so that it compiles. We will also see if we can generalize some of the code that implements operators.

Same as above.

3. We will attempt to fix at least one bug. If we can handle that, we will try to do more bugs given enough time before the project's due date.

Cool.

4. We are trying to add a new feature to Gimp. It will be something small, but we still want to do something that will be interesting. We were thinking of looking into the filters or brush shapes to see what can come of that.

I understand that bug fixes are not sexy and you want something cooler. :-) Well there are so many wanted features that it is hard to give advice. About brush, I know there are some plans on supporting more brush engine (in particular by using libmypaint, if not mistaken). Maybe that's a path to follow if you want to improve brushes? You may have an idea of the biggest planned features there: http://wiki.gimp.org/index.php/Roadmap Though if you have other ideas, we are always happy to consider interesting new concepts.

But the best would be to come on GIMP's IRC where most of the devs are hanging around (respectively in their timezones): #gimp on irc.gimp.org
There you may ask questions if you have any, if you don't understand something, or want to propose, etc.

We understand that this will not increase the speed of Gimp, but it may be something else entirely that may be helpful to someone by chance (as we said in our initial plan).

Thanks for this dialogue. It has been quite helpful to us moving forward.

You are welcome. Don't hesitate to come hang around on IRC. There is no reason to just stop the dialogue. :-) In any case, for the sake of the class, I understand that you have to work fast and just implement "something to show your teacher". In this respect you may not care too much about discussing too much about the best approach and waste time. If that is the case, I fully understand. Just be aware that some things are doomed from the start though (like rewriting base class in C++ as you propose) if the goal is also to merge upstream. Since I find it sad to waste good work and would definitely prefer to see new contributors with upstream patches, well I want to make sure you got this part. In any case, have fun GIMPing! And maybe see you on IRC. :-)

Jehan

Have a great day.

On Tue, Nov 12, 2013 at 4:39 AM, Jehan Pagès wrote:

Hi,

On Tue, Nov 12, 2013 at 5:30 PM, DeVonte Applewhite 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 files.

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 it.

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,

Jehan

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. 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 data structures included in
the 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.
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. 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.

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 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:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Jehan Pagès
2013-12-09 03:56:19 UTC (over 10 years ago)

I am hoping to contribute to GIMP. I have some ideas, but I want input if possible.

Hi,

On Mon, Dec 9, 2013 at 4:35 PM, DeVonte Applewhite wrote:

Hello,

First of all, do not send emails to only me please. You are lucky I check my emails regularly and in particular answer them. Also I am not the one who knows the code the best. If you really want answers, you should send to the whole list. I added it in Cc.

I am trying to just test out the gimpmath portion of the libgimpmath folder. It has the vectors, matrices and other math-related functions in it. I want to just take the contents of this folder, put these contents in a temporary folder that is inside this folder. I'll name that folder temp. then, I want to change the implementation of one of the .c files and test it with a driver program to see the individual functions get invoked. However, I am having a hard time compiling this setup because at times I am not including certain libraries and I do not know the exact location of the gdouble and gint variables that these programs use. Here is my makefile so far. mygimpvector.c is my implementation of the gimp vector.c program. Right now, mygimpvector.c is identical to gimpvector.c except for its name being different. Do you have any ideas?
test: mattest.c mygimpmatrix.c
gcc `pkg-config --cflags --libs glib-2.0` mattest.c mygimpmatrix.c -Wall

Thanks in advance and hope to hear from you soon.

I don't really understand what you are speaking about. Are you modifying core GIMP code (which last time we talked was your project) or just testing out existing libgimp in say a C plugin?

As for all the g* types (gint, gdouble...), they are glib types, so you have to find the adequate glib header to include, but I'm not sure either that is what you are asking me about.

As for your mygimp* files, are they simply reimplementation of the gimp* files similarly named? If so, why do you even bother making a separate file? Why don't you modify inline the existing file, so that you don't have to bother for modifying Makefiles? (you can always keep a copy of the current files if you need side-by-side comparison, but the new implementation should go in the gimp* files)

Also are you trying to modify directly Makefile-s (instead of Makefile.am) and using bare gcc command lines there? This is a very non-portable and broken way. No wonder you have issues. Look the Makefile.am files and try to understand how these work (you can also look for automake tutorials) if really you need to edit the compilation.
But as I said earlier, if the goal is only to provide a new implementation of an existing API, you should not have anything to do to modify the build.

Jehan

On Sun, Nov 17, 2013 at 7:24 PM, DeVonte Applewhite wrote:

Thanks!!! Ah, now I understand. Our initial understanding was that since some parts were made in C++ there would be reason for doing more C++ coding in place of a few C code files. Thank you for clarifying that this plan has large problems and that it would not be merged to the main program (upstream). I think that the brushes are definitely a good route to look into . Thank you for the reference link. Yes, we do not have a large chunk of time, but we definitely will try to spend it as effectively as we can. I will try the IRC channel. It sounds like something I could definitely use since GIMP is a large project that can be overwhelming to understand at once. Glad people are happy and available to discuss questions, suggestions and such. I think my group can make a plan based on this information for sure. Thanks again.

On Sun, Nov 17, 2013 at 6:38 PM, Jehan Pagès wrote:

Hi,

On Mon, Nov 18, 2013 at 12:09 PM, DeVonte Applewhite wrote:

Thank you for your response. We have used your input to clarify our direction on this project. What do you think of this. 1. We will try to make a c++ implementation of gimpvector where we overload
operators and try to string the executable together so that it compiles.

As Sven also answered on the mailing list, GIMP is written in C, not C++. And even though it may happen that some components may be written in C++ if really it helped somehow (for instance when using some third party library in C++ which is the best at what it does), I'm pretty sure our maintainer won't accept any base class in C++, especially for no reason.

Now if that's just for the fun of the experiment and the sake of your class project, go ahead. :-) But don't have your expectations too high, because such code may never make it upstream.

2. We will try to make a c++ implementation of gimpmatrix where we overload
operators and try to string the executable together so that it compiles. We
will also see if we can generalize some of the code that implements operators.

Same as above.

3. We will attempt to fix at least one bug. If we can handle that, we will
try to do more bugs given enough time before the project's due date.

Cool.

4. We are trying to add a new feature to Gimp. It will be something small,
but we still want to do something that will be interesting. We were thinking
of looking into the filters or brush shapes to see what can come of that.

I understand that bug fixes are not sexy and you want something cooler. :-)
Well there are so many wanted features that it is hard to give advice. About brush, I know there are some plans on supporting more brush engine (in particular by using libmypaint, if not mistaken). Maybe that's a path to follow if you want to improve brushes? You may have an idea of the biggest planned features there: http://wiki.gimp.org/index.php/Roadmap Though if you have other ideas, we are always happy to consider interesting new concepts.

But the best would be to come on GIMP's IRC where most of the devs are hanging around (respectively in their timezones): #gimp on irc.gimp.org
There you may ask questions if you have any, if you don't understand something, or want to propose, etc.

We understand that this will not increase the speed of Gimp, but it may be
something else entirely that may be helpful to someone by chance (as we said
in our initial plan).

Thanks for this dialogue. It has been quite helpful to us moving forward.

You are welcome. Don't hesitate to come hang around on IRC. There is no reason to just stop the dialogue. :-) In any case, for the sake of the class, I understand that you have to work fast and just implement "something to show your teacher". In this respect you may not care too much about discussing too much about the best approach and waste time. If that is the case, I fully understand. Just be aware that some things are doomed from the start though (like rewriting base class in C++ as you propose) if the goal is also to merge upstream. Since I find it sad to waste good work and would definitely prefer to see new contributors with upstream patches, well I want to make sure you got this part. In any case, have fun GIMPing! And maybe see you on IRC. :-)

Jehan

Have a great day.

On Tue, Nov 12, 2013 at 4:39 AM, Jehan Pagès

wrote:

Hi,

On Tue, Nov 12, 2013 at 5:30 PM, DeVonte Applewhite 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
files.

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 it.

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,

Jehan

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. 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 data structures included
in
the 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.
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. 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.

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 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:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list