The code LGTM, but I would like to get feedback from @Daniel Martinez Lara (pepeland) to be sure we keep artistic feeling.

@Daniel Martinez Lara (pepeland) could you test this change?

@Falk David (filedescriptor) would love to test this! but i'm not sure how to apply it to my local repository. First time trying to apply a patch, going wrong somewhere.

PS C:\blender-git\blender\source\blender\editors\gpencil> git apply D11153.id36750.diff
error: patch failed: source/blender/editors/gpencil/gpencil_paint.c:3811
error: source/blender/editors/gpencil/gpencil_paint.c: patch does not apply

make sure to be on the blender-v2.93-release branch.

git checkout blender-v2.93-release
make update
git apply D11153.id36750.diff
make

this should work. (also, I believe it is recommended to use cmd on windows instead of powershell but not 100% sure)

@Falk David (filedescriptor) thanks! i've applied the patch.

If i understand what's going on now: when the pressure of the previous point is modified, the new width of the point isn't updated on-screen until the stylus has travelled and the next point has been added to the stroke. This makes it difficult to correctly judge how much pressure should be applied to the static stylus to get the desired result.

Is it possible to force the stroke display to refresh when the pressure of an existing point gets overwritten, so that we have a more representative display of how the stroke will look while changing pressure?

update:

One other thing: having pressure changes only change existing points to make them thicker is faithful to how natural media works, but i wonder whether allowing thinning too may be desirable. i can't think of an obvious downside to allowing change in both directions. It might be worth allowing to see how that feels.

@Tomasz Kaye (bitbutter) It should update. Here is what I am getting (maybe this is different to windows?):

The reason the scaling looks different from a single point to an end-point with more than one point is because of how the gpencil engine works.
Here is an example where I manually scaled up the second to last point and the last point (x5 and x10):

One other thing: having pressure changes only change existing points to make them thicker is faithful to how natural media works, but i wonder whether allowing thinning too may be desirable.

I have tried it, and it feels very unexpected. When you lift your pen (e.g. to finish the stroke), the pressure will often drop. It's pretty annoying really. So I'd vote no on that.

Updated the patch to include the last couple of points. Note that this is now based on master, since I do not think this can be included in 2.93.

ah i guess it might be a windows problem then. Here's a video of my screen. For each dot i was touching the stylus to the surface, gradually increasing pressure, then taking the tip off the surface.

In most cases i get a visible dot when my pen touches, and the size of it only updates when the pen leaves the surface again, but not in between while i'm varying the pressure. Oddly, one of the dots at the end of the video (32 seconds in) did show a more continuous 'growing' effect as i increased pressure.

I tried with both wintab and windows ink but got the same result.

@Tomasz Kaye (bitbutter) Seems like you are just getting fewer pressure updates :/ there is this task T87499 talking about the problems.

hmm. That's odd. Just to check: In other apps the pressure seems to be polling correctly even while the stylus is still. Here's Krita:

Yes, that is what T87499 is about. It's a Blender problem and how we deal with these tablet events (specifically on windows). Grease pencil is just not getting enough events from the GHOST system.

On my tests (Windows) the fix produces unexpectable size changes on the stroke and jumps while drawing, mostly when drawing slowly. Still not that reliable IMO

@Matias Mendiola (mendio) Right, this patch will not look like it works correctly on windows. At least not until we fix the underlying event issue (T87499).

As the result is not as expected, we must keep the patch retained.

Ok that's fine. We will have to come back to this later then.

@Falk David (filedescriptor) Revision to watch for high frequency Wintab is D11508. I'm playing with a "fallback to Win32/low frequency mouse" in the case of a mismatch of Wintab/Win32 cursor position. This will hopefully catch buggy drivers, but also happens when the user has set the tablet to mouse/relative mode.

@Matias Mendiola (mendio) @Antonio Vazquez (antoniov) @Falk David (filedescriptor)

D11508 is now merged, so this revision can be rebased and reevaluated.

In D11153#300245, @Nicholas Rishel (nicholas_rishel) wrote:

@Matias Mendiola (mendio) @Antonio Vazquez (antoniov) @Falk David (filedescriptor)

D11508 is now merged, so this revision can be rebased and reevaluated.

In my tests the patch produces jerky movements that modify the radius while drawing. (Windows)

That's odd, I don't see anything that would cause jerkiness. As a first guess, maybe this is making it more apparent that tablet input is constrained to pixel resolution?

Heads up if D11959 lands it may impact the strategy used in this patch.