Cedric, the problem is that the only vibe your intiial post gave off is a "this is wrong" and a "this is totally wrong". You need to explain the problem in detail (e.g. provide a contrived scenario to demonstrate it) and then suggest (again, in detail) what the proper result should have be instead. You did neither.
As for me, the one problem I have with the "incremental" tool option is that it does not mix with alpha-blending. If I specify an opacity of 50% and use the incremental option, (due to the way GIMP internally processes brush strokes) the end result is brush strokes painted with 99% or so opacity because, with the default brush spacing of 15%, the pixels within the stroke area are receiving about 6 strokes of 'paint'. Yes this is technically correct behavior, but the end result is neither correct nor intuitive (bug #588984) in the eyes of the end user. This is less of an issue when you are painting with 100% opacity to begin with, but it still means that fuzzy brushes end up with very hard edges because along the brush's edge those same pixels are getting painted several times over. Non-incremental painting is at least intuitive: The entire stroke receives a specified, uniform opacity (brush dynamics notwithstanding) and if you need to make multiple strokes over the same area then you can do so in, well, separate strokes. I, too, would like to see an option where you can paint strokes that are of a predictable opacity (as non-incremental painting already does) but simultaneously allows them to overlap with previous strokes, a la Corel Painter. But I'm at a loss, even conceptually, on how that could be done. On a tangent, one trick I found with painting straight lines is that since you need to click to set a starting point before using the Shift modifier, if you Undo the initial click you can still use the Shift modifier to paint a straight line with a single stroke without that original poin being applied to the canvas. This can be useful in some cases for single lines at a time.... -- Stratadrake [email protected] -------------------- Numbers may not lie, but neither do they tell the whole truth. > Date: Sat, 28 Jan 2012 17:51:40 +0100 > From: [email protected] > To: [email protected] > CC: [email protected] > Subject: Re: [Gimp-developer] Non-incremental painting > > Mitch & "Dude", > > I did not ask for your generousity. I reported this flaw on the > bugtracker, was asked to bring it up on the list, did so, and, frankly, > don't give a tiny bit about how emotionally sensitive you are over it. > > And if you are unable to discuss the point at hand and are only capable > of returning insults, be my guest, but don't expect any response other > than this because I've better things to do with my time than leading > this kind of stupid argument. > > Anyone else willing to comment on the actual technical issue, > irrespective of how "arrogant" I sound or how much my "tone sucks", I'd > welcome it. > > However, Michael is maintaining this list and "politely" asked me to > leave, hence, I will only reply to you in private for not to offend him > any further. > > On Sat, Jan 28, 2012 at 07:39:35PM +0400, Alexandre Prokoudine wrote: > > On Sat, Jan 28, 2012 at 6:33 PM, Cedric Sodhi wrote: > > > > > If anyone can think of a usecase where that non-intuitive, unpredictable > > > painting mode is actually useful, please prove me wrong. > > > > > > Until then, I interpret the mere existance of that painting mode as an > > > excuse to not admit one of the most serious flaws in gimp with regard to > > > painting. > > > > > > To be blunt, as long as there is no way for a painter to properly > > > anticipate the color in which he draws unless he draws in short, > > > non-self-overlapping strokes (which, admittedly, is typical for > > > water-color et al), gimp may be a powerful graphics-editor but remains > > > nothing but a toy for painting (and all efforts related to painting such > > > as providing well-designed presets remain futile). > > > > Dude, > > > > Replacing lack of technical expertise with trolling doesn't work. Not > > everyone is as generous as las to spend two friggin hours explaining > > you how automation on MIDI events works, while facing your, frankly > > speaking, arrogant behaviour. The trick isn't going to work every > > time, and definitely not in GIMP lists. > > > > You are more than welcome to ask question and even question decisions, > > but don't expect everyone to just rush having a conversation with you. > > > > Alexandre Prokoudine > > http://libregraphicsworld.org > > _______________________________________________ > > gimp-developer-list mailing list > > [email protected] > > http://mail.gnome.org/mailman/listinfo/gimp-developer-list > _______________________________________________ > gimp-developer-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gimp-developer-list
_______________________________________________ gimp-developer-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gimp-developer-list
