As an addendum, I think another (perhaps less intrusive) option to improve this could be to provide a sort of "global" slider that all preset sizes are scaled relatively by. So if the preset saves the brush with a tip size of 100px, and the slider is at 1, the brush will end up being 100px. If the slider is pulled down to .5, the preset will render at 50px, and if the slider is pulled up to e.g. 2, the preset will render at 200px.

This way, the workflow of people who would not want all presets to scale with document size would not be disrupted, and for people who do want this feature, it'd just be a matter of setting the slider once upon document creation, which isn't much hassle. (Perhaps the value of the slider could be saved with the document.)

Hi jon, could your report be related to Bug 338845?

Hey mvowada,
it's related, but does not solve the same problem IMO.

For instance a user might do some erasing and zoom in just to see better which pixels are affected by the eraser preset, but not intend the eraser to become smaller (which is what would happen if preset size was held constant relative to screenspace), as this affects e.g. the curvature/"hardness" of the eraser and how effective it works (area covered by a stroke). If zooming in by 4x scales down the brush by 4x, that changes quite drastically how soft the antialiasing/softness on the edge of the brush appears. Another example could be if you're drawing hair or other types of strands, which you would absolutely not want to be affected by zoom level. Or maybe if you're just inking, and you need to zoom in a little to see more detail.

I can see that screenspace-constant preset sizes can be quite useful when doing a painting workflow where going from large areas to detailing smaller and smaller areas, as it alleviates the need of scaling your brush down smaller and smaller as you work more detailed (you just zoom in instead), but it's quite intrusive, as it changes the way your presets work while you are painting, whereas what I'm proposing only ever adjusts the presets based on the (physical?) document size, so it will always be consistent for one document -- and if this adjustment is not to your taste, you could use the proposed global preset size slider to adjust the brush size. 

I think defining brush size relative to document size (as defined in cm or whatever) is always the right thing to do by default, as it makes it feel more consistent at what size brush strokes appear across different documents. E.g. if the user decides to lower or up the resolution of a document in order to achieve more detail or better performance, but keeps the size of the document in e.g. cm constant, it makes no sense that by default all brushes now have an unusably small/big size. At least I can't imagine that that would ever be a desired effect.

OTOH I think that holding brush size constant relative to screenspace is a thing that should occur optionally.

Hi Jonathan,
thank you for the clear explanation.
Do you know by chance if the global slider you have described in comment #2, has been implemented by some other programs before?
Assuming we all are skilled artists, nonetheless I think that a similar feature would be welcome.

I'm not aware of any software that implements the global slider as such, but I'm fairly sure a lot of software defines their brushes relative to document size. I can do some research into various software packages if this information is desirable. It might be that some of them implement the global slider such that if you use some brush X, make it larger by 20%, then switch to some brush Y, that brush Y is also now 20% larger.

I'm not sure if the slider is really very useful. I mostly thought of it as a bandaid for people who dislike brushes that are defined relative to the physical size of the document when I first wrote the bugreport, but upon further reflection, if you want to keep the current behaviour, you could simply create your documents with a constant resolution:ppi ratio (perhaps the "new document" creation dialog could make this easy.) The slider would in effect just be a way to dynamically up/decrease the documents ppi.

However I could see it being useful as being implemented in the way described above, where the scaling a user applies to the brush (e.g. by shift-dragging) is kept/re-applied when the user switches to a different preset. So this would mean the slider is there "implicitly". Different kinds of brushes (e.g. eraser and pencil) would still have their difference in size applied in relative terms, so if I use the pencil at 2x its normal size, the eraser would also be 2x its normal size when switched it. This could allow the user to create a workflow where he/she switches between a set of presets (e.g. 5 different paint brushes) constantly while painting, and as they home in on the detail, globally decrease the size for all brushes they are constantly switching between, without having to alter the documents PPI for this all the time. From what I've seen, the way users solve this problem now is by having several presets (see e.g. the "detail" brushes in David Revoys brushkit v6)

Anyway, I would say the whole "slider" idea overlaps with the screenspace-constant-brushsize in what role it fullfills (I currently tend to think the "implicit slider" idea fullfills the role better than the screenspace-constant-brushsize), so if desired I can propose it in the screenspace-constant bugreport (or make a new one), but I think it can be dropped from this bugreport, as it's not genuinely related to the consistent-brushsizes-across-documents issue.

Sorry for the long text, I need to learn to keep myself brief :)

Created attachment 92867 [details]
Implicit brush size across resolutions.

> It might be that some of them implement the global
> slider such that if you use some brush X, make it larger by 20%, then switch
> to some brush Y, that brush Y is also now 20% larger.

Sounds very logical.
By setting the variance once for all (implicitly), reminds me of the input pressure global curve in the program settings (main menu > Cofigure Krita... > Tablet settings).

> but upon
> further reflection, if you want to keep the current behaviour, you could
> simply create your documents with a constant resolution:ppi ratio (perhaps
> the "new document" creation dialog could make this easy.) The slider would
> in effect just be a way to dynamically up/decrease the documents ppi.

I think I'd prefer better the other way around.
The slider would dynamically increase or decrease the brush size.

> However I could see it being useful as being implemented in the way
> described above, where the scaling a user applies to the brush (e.g. by
> shift-dragging) is kept/re-applied when the user switches to a different
> preset. So this would mean the slider is there "implicitly". Different kinds
> of brushes (e.g. eraser and pencil) would still have their difference in
> size applied in relative terms, so if I use the pencil at 2x its normal
> size, the eraser would also be 2x its normal size when switched it.

So far so good.

> This
> could allow the user to create a workflow where he/she switches between a
> set of presets (e.g. 5 different paint brushes) constantly while painting,
> and as they home in on the detail, globally decrease the size for all
> brushes they are constantly switching between, without having to alter the
> documents PPI for this all the time.

But is not this the exact same feature of Bug 338845 (lock the brush sizes to the zoom levels)?

> From what I've seen, the way users
> solve this problem now is by having several presets (see e.g. the "detail"
> brushes in David Revoys brushkit v6)

True!

> Anyway, I would say the whole "slider" idea overlaps with the
> screenspace-constant-brushsize in what role it fullfills (I currently tend
> to think the "implicit slider" idea fullfills the role better than the
> screenspace-constant-brushsize), so if desired I can propose it in the
> screenspace-constant bugreport (or make a new one), but I think it can be
> dropped from this bugreport, as it's not genuinely related to the
> consistent-brushsizes-across-documents issue.

No, I wouldn't consider yours as a duplicate of Bug 338845. I think it's a whole different feature, that is (see image):
lock the brush size appearance across different image resolutions.

>  But is not this the exact same feature of Bug 338845 (lock the brush sizes to the zoom levels)?

I'm not 100% sure (we should perhaps ask one of the people who want the screenspace-constant-brush-size feature, as they probably understand the issue they are trying to solve better), but I think the slider-idea fullfills essentially the same role, in that it gives the user an optional way of "working at different levels of details". So lets say 50% zoom -> rough blocking mode, 100% zoom -> detail work mode. The "slider" (whether implemented as explicit slider visible in the UI, or toggable feature to preserve relative scaling changes between different presets) basically does the same thing, but decouples it from the zoom (brushes used normally -> rough blocking mode, enable "keep brush scaling between presets" and make brush finer -> detail work mode.

Yes, I agree that the "define presets relative to physical document size" does not overlap with Bug 338845, but the slider-idea as such does, so it probably makes sense to let this bugreport be purely for the "presets relative to physical document size" issue (which, IMO, is a sane, enabled-by-default feature), and either make a new wishbug for the slider idea, or suggest it in Bug 338845, since the slider idea might not really be needed if the screenspace-constant-brush-size feature + "define presets relative to physical document size" (as described in this bug) is implemented.

Created attachment 92891 [details]
Implicit brush size across resolutions.

Here I've uploaded an image to illustrate my proposal.
I don't know if it would be feasible.

(Note: there's a typo in it, actually the variance would range from x1,00 to x999,99 - corresponding to min/max ppi).

WISHGROUP: Needs proposal and design: needs discussion among artists to define scope first

Once there is a solid proposal we can start a project.