I would not give a critique unless I did a thorough review of the current incarnation of re-architecture with some benchmarks on stressful average work flow that could be expected from a computer graphics artist or painter.
I will say that the Gimp 'core rewrite' has been a project in development since the early 2000's. I have never seen a clear design document explaining what this new core is suppose to achieve and for what uses Gimp expects to be used by professional level Artists workflows.
The last development that I was paying attention to was the decision to switch to GEGL for there core compositing and pixel engine. But it looked like it would simply be easier and probably better to start from scratch and build an entirely new software build around a 32bit image architecture rather then try and retrofit there 8bit custom build compositing system.
I will also note that they decided to invest there limited resources into upgrading the gui from GTK2 to GTK3 rather then focus that energy on the core. That shows rather skewed priority focus for a software that has some serious issues.
I don't see the port to GTK3 as being such high priority. It's not even on the roadmap to 2.10; The roadmap seem sane to me.
I don't think the program was intented specifically for painters, but it did include the MyPaint brush engine. And I find the program easier to use with every new version.
The only thing I can truly complain is the slow speed at which the versions are being released - but then again - the program never crashed on me - which speaks of the high quality of the code behind it - and quality takes time. I think the blame for the speed lies in the lack of developers resources.
But this time I can address this issue: I commited $8/month, and I'm promoting the campaign heavily.
Well, generic_user here makes here a typical mistake of thinking that performance is the topmost priority during development. Whereas the usual development pattern is "write first, optimize later".
Also, thank you for your support. We do appreciate it!
I can't believe you're saying this. Quality and performance must be the topmost priorities in any graphics application. That's something you have to design your architecture around, not a thing you can optimize later. Poor performance and poor quality are no gos for any artist serious about work. Having an application that is too slow to be used or mangles the quality of your work is as bad as not working at all.
Actually, you can't say it works if it can't provide a reasonable performance to get the job done!
How can performance not be a priority?
It's not that performance it's not a priority, it's just that it you can achieve it later by optimizations.
"Premature optimization is the root of all evil" said once a wise man (was it Dijkstra?);
Anyway, GIMP is getting faster - with 2.9 you can already use GPU accelerated operations and plugins, if that is your concern.
What you don't want is a program that crashes all the time, or one that is so convoluted (because "performance"), that nobody is able to develop it further, since nobody can wrap his head around of all the implication of a modification.
No, it's not about premature optimization but designing towards performance. It's always a balancing act but the earlier you make the right choices the better.
There are mandatory questions during the design process, before writing a single line of code. "Is it going to be fast enough?" is one of them and you can't answer it by saying "I'll figure out how to optimize it later" or "computer power will eventually catch up".
Oh, and btw. Stop using the "GPU accelerated" argument as it was a silver bullet. GPU is not a crutch to make slow operations barely usable, it should be used as an extra performance boost for operations that already work.
GPU is quite the silver bullet, IMHO. It's a chip specifically designed for graphics, it's a Graphical Processing Unit. You can't expect the performance of a general purpose unit to be even anywhere close.
There are cases where coding for performance from the get-go is the way to go - think the_silver_searcher vs ack; there are cases where "computer power will eventually catch up" - the GNU coreutils did just that, they where coded for a system where a large amount of RAM was available(even if at the moment, in the '70's it wasn't), and removed many limitation that the proprietary tools had at those times.
But in a large program, that aims to grow even larger as features add up, performance is not your primary concern. If you have good abstractions, and you optimize at pixel conversion layer by 50% (say babl), all those optimization will add up. If you write your code in assembler, for speed's sake, you'll never surpass the complexity of MS Paint.
I worked on a web application that was a bit over 100k lines of code (at least the subsystems I had access to) - some bad architetural decisions made progress stall, and features were delayed by as much as half a year. Every change at deeper levels broke all kind of things at the UI level. Those were some shitty days, trust me.
Thanks for your reply. You present some interesting points.
* Project management.
* Goal/benchmark definition.
* Human resource allocation.
I can't decide if what you say is truly so. One thing that I know, though, is that the old GIMP has been very useful to me for editing images (nothing fancy). I'm not an artist/painter but if I were, I'd start that with Krita instead of GIMP. In my mind, GIMP is more of a toolbox for doing the boring stuff like cropping/converting/annotating/correcting some random images and saving them in various formats. Gaining proper color management would be a good thing in my opinion, even if everything else stayed the same.
If Gimp works for you then use it. But I think you will find that even for simple image manipulation Krita is a faster easier to use editor at this point.
My concern is with Professional quality tools for artists. These tools already exist on Linux but they are predominately closed source. If Linux and OSS is going to be an option for Artists then the tools have to meet the same high quality standards that other professions that use Linux expect. But in graphics this is not the case and has not been the case for many years.
The best way to encourage the momentum for better tools is to support those projects that take the quality of there software seriously and have some urgency. The projects I have mentioned previously have demonstrated that they have that focus.
There's one artist that uses FLOSS to draw and make a living out of it, David Revoy.
He's using Krita as his main painting tool, but:
"Gcolor2 is a colorpicker, Inkscape my favorite vector editor, Gimp for manipulating images and Shutter for taking advanced screenshots."
I don't see why we shouldn't support the development of both programs. I personally like GIMP better, maybe just because I'm used with the interface, and I don't do paintings, only image manipulations.
I'm simply offering my opinion. If you want to donate to Gimp developers thats your choice.
Krita has a very refined process for development donations. They collect donations through a Professional funding site not a personal Patreon account and there is a clear time frame for development and a clear set of features that will be 'Finished' at the end of the development cycle.
They have successfully delivered with this model and the people who gave them money got what they paid for and will more then likely fund them again and other projects.
Can you say the same for gimp? No, someone might give some money to a Gimp developers Patreon making all sorts of promises that never get finished. The person who gave that money will probably never contribute again.
Thats a big problem for every OSS graphics project now. We have to give people who are willing to put down the money what they expected to get or they will stop funding.
Its important that the most professional, serious projects get promoted and funded to serve as a model for other projects to follow. And to grow the amount of users that feel comfortable giving there money.
You can see the same sort of professionalism with Blender and Natron development. And they also are producing quality software. If the project is fallowing this professional model then they deserve to be promoted IMO. But simply putting a bunch of promises on a personal Patreon and asking for money will do more harm then good to the larger OSS graphics community.
I would not give a critique unless I did a thorough review
But you made up an argument about driving off experienced developers. So what's actually stopping you from making more stuff up?
I will say that the Gimp 'core rewrite' has been a project in development since the early 2000's.
Nope. It started around 2006 at small steps.
I have never seen a clear design document explaining what this new core is suppose to achieve
So you've never visited gegl.org?
and for what uses Gimp expects to be used by professional level Artists workflows.
So you've never visited gui.gimp.org?
I will also note that they decided to invest there limited resources into upgrading the gui from GTK2 to GTK3 rather then focus that energy on the core.
Wrong. 2.10 is all about rewriting the core. We need GTK+3, because GTK+2 has tablet support is broken on Windows.
Comments
Can you comment on the substantial redesign of the GIMP that will be in the next major version?
I would not give a critique unless I did a thorough review of the current incarnation of re-architecture with some benchmarks on stressful average work flow that could be expected from a computer graphics artist or painter.
I will say that the Gimp 'core rewrite' has been a project in development since the early 2000's. I have never seen a clear design document explaining what this new core is suppose to achieve and for what uses Gimp expects to be used by professional level Artists workflows.
The last development that I was paying attention to was the decision to switch to GEGL for there core compositing and pixel engine. But it looked like it would simply be easier and probably better to start from scratch and build an entirely new software build around a 32bit image architecture rather then try and retrofit there 8bit custom build compositing system.
I will also note that they decided to invest there limited resources into upgrading the gui from GTK2 to GTK3 rather then focus that energy on the core. That shows rather skewed priority focus for a software that has some serious issues.
http://wiki.gimp.org/wiki/Roadmap
I don't see the port to GTK3 as being such high priority. It's not even on the roadmap to 2.10; The roadmap seem sane to me.
I don't think the program was intented specifically for painters, but it did include the MyPaint brush engine. And I find the program easier to use with every new version.
http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_visio...
The only thing I can truly complain is the slow speed at which the versions are being released - but then again - the program never crashed on me - which speaks of the high quality of the code behind it - and quality takes time. I think the blame for the speed lies in the lack of developers resources.
But this time I can address this issue: I commited $8/month, and I'm promoting the campaign heavily.
Well, generic_user here makes here a typical mistake of thinking that performance is the topmost priority during development. Whereas the usual development pattern is "write first, optimize later".
Also, thank you for your support. We do appreciate it!
I can't believe you're saying this. Quality and performance must be the topmost priorities in any graphics application. That's something you have to design your architecture around, not a thing you can optimize later. Poor performance and poor quality are no gos for any artist serious about work. Having an application that is too slow to be used or mangles the quality of your work is as bad as not working at all. Actually, you can't say it works if it can't provide a reasonable performance to get the job done! How can performance not be a priority?
It's not that performance it's not a priority, it's just that it you can achieve it later by optimizations. "Premature optimization is the root of all evil" said once a wise man (was it Dijkstra?);
Anyway, GIMP is getting faster - with 2.9 you can already use GPU accelerated operations and plugins, if that is your concern.
What you don't want is a program that crashes all the time, or one that is so convoluted (because "performance"), that nobody is able to develop it further, since nobody can wrap his head around of all the implication of a modification.
No, it's not about premature optimization but designing towards performance. It's always a balancing act but the earlier you make the right choices the better. There are mandatory questions during the design process, before writing a single line of code. "Is it going to be fast enough?" is one of them and you can't answer it by saying "I'll figure out how to optimize it later" or "computer power will eventually catch up".
Oh, and btw. Stop using the "GPU accelerated" argument as it was a silver bullet. GPU is not a crutch to make slow operations barely usable, it should be used as an extra performance boost for operations that already work.
GPU is quite the silver bullet, IMHO. It's a chip specifically designed for graphics, it's a Graphical Processing Unit. You can't expect the performance of a general purpose unit to be even anywhere close.
There are cases where coding for performance from the get-go is the way to go - think the_silver_searcher vs ack; there are cases where "computer power will eventually catch up" - the GNU coreutils did just that, they where coded for a system where a large amount of RAM was available(even if at the moment, in the '70's it wasn't), and removed many limitation that the proprietary tools had at those times.
But in a large program, that aims to grow even larger as features add up, performance is not your primary concern. If you have good abstractions, and you optimize at pixel conversion layer by 50% (say babl), all those optimization will add up. If you write your code in assembler, for speed's sake, you'll never surpass the complexity of MS Paint.
I worked on a web application that was a bit over 100k lines of code (at least the subsystems I had access to) - some bad architetural decisions made progress stall, and features were delayed by as much as half a year. Every change at deeper levels broke all kind of things at the UI level. Those were some shitty days, trust me.
So we, in fact, completely agree.
Thanks for your reply. You present some interesting points.
* Project management.
* Goal/benchmark definition.
* Human resource allocation.
I can't decide if what you say is truly so. One thing that I know, though, is that the old GIMP has been very useful to me for editing images (nothing fancy). I'm not an artist/painter but if I were, I'd start that with Krita instead of GIMP. In my mind, GIMP is more of a toolbox for doing the boring stuff like cropping/converting/annotating/correcting some random images and saving them in various formats. Gaining proper color management would be a good thing in my opinion, even if everything else stayed the same.
If Gimp works for you then use it. But I think you will find that even for simple image manipulation Krita is a faster easier to use editor at this point.
My concern is with Professional quality tools for artists. These tools already exist on Linux but they are predominately closed source. If Linux and OSS is going to be an option for Artists then the tools have to meet the same high quality standards that other professions that use Linux expect. But in graphics this is not the case and has not been the case for many years.
The best way to encourage the momentum for better tools is to support those projects that take the quality of there software seriously and have some urgency. The projects I have mentioned previously have demonstrated that they have that focus.
There's one artist that uses FLOSS to draw and make a living out of it, David Revoy.
He's using Krita as his main painting tool, but: "Gcolor2 is a colorpicker, Inkscape my favorite vector editor, Gimp for manipulating images and Shutter for taking advanced screenshots."
https://www.davidrevoy.com/article316/ubuntu-16-04-for-my-di...
I don't see why we shouldn't support the development of both programs. I personally like GIMP better, maybe just because I'm used with the interface, and I don't do paintings, only image manipulations.
I'm simply offering my opinion. If you want to donate to Gimp developers thats your choice.
Krita has a very refined process for development donations. They collect donations through a Professional funding site not a personal Patreon account and there is a clear time frame for development and a clear set of features that will be 'Finished' at the end of the development cycle.
They have successfully delivered with this model and the people who gave them money got what they paid for and will more then likely fund them again and other projects.
Can you say the same for gimp? No, someone might give some money to a Gimp developers Patreon making all sorts of promises that never get finished. The person who gave that money will probably never contribute again.
Thats a big problem for every OSS graphics project now. We have to give people who are willing to put down the money what they expected to get or they will stop funding.
Its important that the most professional, serious projects get promoted and funded to serve as a model for other projects to follow. And to grow the amount of users that feel comfortable giving there money.
You can see the same sort of professionalism with Blender and Natron development. And they also are producing quality software. If the project is fallowing this professional model then they deserve to be promoted IMO. But simply putting a bunch of promises on a personal Patreon and asking for money will do more harm then good to the larger OSS graphics community.
https://git.gnome.org/browse/gimp/log/?qt=author&q=pippin
https://git.gnome.org/browse/gimp/log/?h=pippin%2Flinear-is-...
https://git.gnome.org/browse/gegl/log/?qt=author&q=pippin
https://git.gnome.org/browse/babl/log/?qt=author&q=pippin
Commits speak louder than baseless accusations.
But you made up an argument about driving off experienced developers. So what's actually stopping you from making more stuff up?
Nope. It started around 2006 at small steps.
So you've never visited gegl.org?
So you've never visited gui.gimp.org?
Wrong. 2.10 is all about rewriting the core. We need GTK+3, because GTK+2 has tablet support is broken on Windows.