After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 623734 - No brush outline with dynamics set to 'size' on 'pressure'
No brush outline with dynamics set to 'size' on 'pressure'
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: Tools
2.8.10
Other All
: Normal blocker
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
: 652329 738006 783800 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-07-07 08:45 UTC by kore
Modified: 2018-05-24 12:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description kore 2010-07-07 08:45:41 UTC
Setting brush dynamics to change size with pressure makes brush outline disappear when stylus is not touching tablet surface. Once you start drawing, the outline appears.

Reproduce:
- Choose any brush, custom or not;
- In mapping matrix check the 'pressure'/'size' box.

Expected result:
When hovering stylus over the tablet, outline of maximum brush size is shown.

Actual result:
No indication of pointer location and size at all.
Comment 1 Alexia Death 2010-07-07 19:10:04 UTC
The expectation is wrong. The point of the outline is to show a preview of the pixels. It shows accurately that no pixels are modified.. The outline appears when you apply the pressure and there are pixels that will be changed.

Why do you think that full size outline would be correct? It would totally void the point of a preview.
Comment 2 kore 2010-07-08 05:41:36 UTC
But it did work like that in previous versions (including 2.7.0).

Judging by the size of the outline, one can roughly estimate the outcome of applying pressure - now (without outline) I can't even see where I'm going to draw, thus I have to turn on pointer / crosshair, and it proved to by totally inconvenient.

I'll try installing GIMP on a Windows machine today to see if this issue appears there too.
Comment 3 Alexia Death 2010-07-08 06:14:55 UTC
It's a feature and its not OS dependent.  I added a lot of code to make the outline respect dynamics. Its value is most seen when you use angle mapings and lets you predict how your stamp lands.

It is mildly inconvinent in size mapings, but showing a full size stamp while hovering is out of the question. Would some threshold work for you, so a tiny stamp is shown IT will not be correct for the current state of prsssure, witch is zero, but might alleviate the inconveience.
Comment 4 Alexia Death 2010-07-08 06:25:02 UTC
BTW, are you using your tablet in window mode? Normally you have the system cursor, if outline disappears.
Comment 5 kore 2010-07-08 07:33:53 UTC
Yes, adding threshold will be most convenient. The feature in itself is very nice, the only problem is to know the location of the cursor.

As for the tablet modes, I checked the window mode, and it really has some sort of pointer when stylus doesn't touch the tablet; alas, for me personally this mode is rather uncomfortable.

Thanks for the fast response, guess this bugreport can be closed now.
Comment 6 Meshach Mitchell 2010-08-10 20:05:51 UTC
I'd like to add a consideration, since I have this frustrated me as well.

Many of the "preview" values that affect the size/shape of the brush are actually taken from the current input device properties (direction, pressure, velocity) _during_ the drawing process, i.e., when the brush is down. 

These properties, being undefined when the brush is up, shouldn't factor into the calculation, IMHO, but should default to reasonable values. "Reasonable" here meaning "so that I don't have to guess where my cursor is going." It really is blindingly irritating.

Actually, an argument for defaulting to max size is that I know that hard as I may press, this is the biggest this brush is going to get on the current settings, so I know that once I start the stroke, I have an upper limit in mind. This is actually much more valuable to me than a preview that becomes irrelevant as soon as I start to draw _anyway_.

I would have at least liked to see a configuration option for trading off some of this accuracy for a bit more stable pointer indicator.
Comment 7 Sven Neumann 2010-08-22 15:59:34 UTC
I agree with Meshash here. IMO we should start a discussion about this on the gimp-developer list.
Comment 8 Alexia Death 2010-08-22 16:42:09 UTC
I'm starting to think that the problem is specific to pressure and that showing a pressure=1 outline if pressure is 0 would cover most needs without breaking the stamp prediction, so I'm going to implement that now, and then we can see what else is problematic.

There are a lot of things relating to dynamics I don't know what to do about actually, like interaction with settings in GIH brushes, so by all means, please feel free to start a thread.
Comment 9 Michael Schumacher 2011-06-15 21:35:49 UTC
*** Bug 652329 has been marked as a duplicate of this bug. ***
Comment 10 Timofei Shatrov 2011-12-18 16:39:33 UTC
The real brush size should be shown at least when using [ and ] to change brush size. Otherwise there's no visual cue for how large the brush is.
Comment 11 Michael Natterer 2014-04-09 13:01:16 UTC
This fixes the case of "no cursor shown at all" in both master and gimp-2-8:

commit fb2ecd9f509f92fc6674dc0751bba889c8195b1e
Author: Michael Natterer <mitch@gimp.org>
Date:   Wed Apr 9 14:30:46 2014 +0200

    app: don't create a fallback crosshair in gimp_brush_tool_create_outline()
    
    Instead, draw the crosshair in gimp_brush_tool_draw() if create_outline()
    didn't return an item *and* if there is no brush tool cursor.
    
    In gimp_source_tool_draw(), don't add an additional crosshair if
    create_outline() returned an item.
    
    This fixes both "no cursor at all" and "both outline and crosshair
    shown" for certain prefs settings conbinations (bug #623734).
    
    (cherry picked from commit e8459beb2448bcb526df429a944070169463aca5)

 app/tools/gimpbrushtool.c  | 26 +++++++++++++-------------
 app/tools/gimpbrushtool.h  |  3 +--
 app/tools/gimpsourcetool.c | 45 ++++++++++++++++++++++++++++-----------------
 3 files changed, 42 insertions(+), 32 deletions(-)
Comment 12 Michael Natterer 2014-04-11 23:17:25 UTC
This should fix the issue in master:

commit 66010e6c6d4da6798d9b09851d0e91ebd6db17a6
Author: Michael Natterer <mitch@gimp.org>
Date:   Sat Apr 12 01:13:11 2014 +0200

    Bug 623734 - No brush outline with dynamics set to 'size' on 'pressure'
    
    Improve the logic in gimp_brush_tool_draw() and draw a brush-sized
    circle if the actual brush outline got scaled away by dynamics.

 app/tools/gimpbrushtool.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++++------------------
 1 file changed, 49 insertions(+), 18 deletions(-)
Comment 13 Michael Natterer 2014-10-08 23:54:17 UTC
*** Bug 738006 has been marked as a duplicate of this bug. ***
Comment 14 roberber 2015-01-28 14:56:40 UTC
I'm also very affected by this “feature” of not to be able to see the outline of maximum brush size. I think that is not changed in the last stable version (GIMP 2.8.14 ). ¿Is there in any beta version? I would like to try.

Thank you very much for the, otherwise, excellent work with the program.
Comment 15 Michael Natterer 2015-02-14 15:34:54 UTC
There is the unstable development version. If you are on Windows
you can use the nightly builds at http://nightly.darkrefraction.com/gimp/
Comment 16 roberber 2016-09-15 11:18:32 UTC
I’ve tried the last stable version of Gimp and the behavior of the outline of the brush is the same. In the meantime, after my last entry (a year and half ago) I discovered Krita and I’ve been working with it until now, but it’s a pity not to paint and draw also with Gimp when it has almost everything to do it even better. So I’ve decided to try to explain again, even with my deficient english, the point of view of some users that perhaps are, as me, professional illustrators.

It seems to be a conception problem: the issue appears when is used a pressure sensitive tablet (a cintiq in my case) and a brush with the pressure-size option on. Alexia Death said:
“The point of the outline is to show a preview of the pixels.”
“The outline appears when you apply the pressure 
and there are pixels that will be changed.”
In my opininon, there is a temporal incoherence in this last sentence: apply the pressure (present) VS will be changed (future). What actually happens now is that when you apply the pressure, you see pixels being changed AND, over it, the outline of the brush changing in real time. Before to apply the pressure you see nothing (or just a position indicator). That is: or redundant feedback or almost no feedback at all.

As I see it, the point of a preview is, literally, to view what will be, in this case, to be predictable.  I understand, as Alexia said: "I added a lot of code to make the outline respect dynamics." and I hardly can imagine how much work it means to implement this function: for me to be able to develop a digital program as Gimp or a feature for it is like a matter of witchcraft and I admire it a lot, but with this configuration I lost completely the feeling of the size of the brush. I’ve been trying to find an alternative way of painting and also try to work as is, but always with the same result: it’s irritating. While painting, I use to change continuously the brush size and the zoom, and to know the parametric size of the brush is not enough: I need to feel it. Along the years, not only with Gimp, to see the full size of the brush has demonstrated to be, for a lot of users, intuitive and effective.

So, I only ask for one thing: to have the choice to by-pass that function. 

It could be in preferences, for example checking “Show always full size outline”. 

I hope to have been clear enough to explain why I think the status of this theme is not resolved or fixed. If is not, please, say it. 

Thanks!
Comment 17 Michael Natterer 2016-09-21 17:32:27 UTC
Reopening so we can look into this again.
Comment 18 Jehan 2017-03-24 03:18:21 UTC
At next LGM, we will have 2 painters with us (Aryeom and Jose). Let's discuss this report with them.
Comment 19 jose americo gobbo 2017-06-17 01:30:09 UTC
So, effectively the comment#16 is a good explanation of my issue reported on this https://bugzilla.gnome.org/show_bug.cgi?id=783800.

If you use the stylus tablet and enabled Size x Inputs on paint dynamics is not possible have the outline preview and is difficult understand the size brush... is necessary do brushstrokes to calibrate the brush size during each change in the painting session.

Normally on the painting sessions we must change the range of sizes, many and many times, and have a preview before each brushstroke is very important.
Comment 20 jose americo gobbo 2017-06-17 01:33:30 UTC
*** Bug 783800 has been marked as a duplicate of this bug. ***
Comment 21 Jehan 2017-12-01 18:17:12 UTC
Aryeom also thinks that the current behavior is weird and would prefer to have the brush outline at its max size (i.e. the brush size) as well.

Reading this thread, it feels like none of the painters who use GIMP daily actually like the no-outline behavior when size is mapped to pressure. I think even the brush-size circle (cf. comment 12) is not practical enough as soon as you use a brush with not symmetrical shape (and in particular not circular) because even if the size will be different when pressing, seeing a preview before-hand can still give a good idea of the shape at least.

So unless someone comes with a really good explanation of why not showing the brush outline is a good idea, I will work into changing this.
Comment 22 default_357-line 2017-12-03 22:57:50 UTC
Maybe the way to go is to both show the full-size brush, in grey, and the current brush size in the middle of it? So you can preview the shape you'll use but don't have any sudden jumps in brush size.
Comment 23 Jehan 2017-12-03 23:55:38 UTC
(In reply to default_357-line from comment #22)
> Maybe the way to go is to both show the full-size brush, in grey, and the
> current brush size in the middle of it? So you can preview the shape you'll
> use but don't have any sudden jumps in brush size.

Not sure I understand what you are saying.
The full-size and current brush size are the same thing.

In any case, I don't see the problem of showing the full-size brush. Yes that is likely not what will be printed, so what? The goal of the preview is to give useful information.

Following this logics, we should also not show a preview when you have a dynamics with randomness because what you see is likely not what will be printed upon clicking.
I mean, even when the dynamics is pretty straightforward, anyway the printing is different from preview. If you map size to tilt for instance, upon clicking, the chances of you having *exactly* the same angle as a hundredth seconds before when you saw the preview are nearly none.

That's ok. You gave some information in both cases (even with a random dynamics, you at least have shape, position…). That's what the brush preview is for.

The more I think of it, the more I am thinking that this whole thing was just overthinking the preview-to-reality mapping. I'll look into this code as soon as I can.
Comment 24 Jehan 2017-12-04 23:02:59 UTC
Setting to blocker mostly because I started to look into it.
Comment 25 GNOME Infrastructure Team 2018-05-24 12:48:55 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/335.