Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iPad Pro [CODE FIX!] Pencil pressure error at start of stroke in 3rd party apps (ATTN: art/note app devs)
- Thread starter Atomic Walrus
- Start date
- Sort by reaction score
I should add that not every developer having an issue with their brush simulation right now is actually showing THIS bug. It seems like a lot of the note software (Notability in particular) might have this specific bug, but when you get to Proceate you're seeing something different:
They're applying the corrections, but they're also applying way too much pressure smoothing (considering that you can't adjust it) and they're applying it preemptively on the uncorrected pressure data. This means that when you get bad (temporary) data from the API it's getting propagated into your whole stroke by the smoothing code and the effect won't be fixed even when the correction is processed. Basically it just shows a fundamental lack of understanding of the predictive functionality ("prediction" touches are clearly predictions, but so is any pressure data thats flagged as "expecting update.") You can ignore these "predictions" and only render the line when you get final data, but this will return you to Wacom/N-trig level of latency.
When you print the raw pressure data directly on screen with a large line width range you will see a lot of correction occurring (very fast but highly visible at large brush sizes) which is what Procreate is trying to avoid with the smoothing, but IMO it's much better to be able to get the raw pressure data even if it means being able to see the prediction tricks at work. The Pencil has impressively responsive pressure sensitivity, but we're not seeing it because everyone is trying to smooth out the data.
TL;DR Regular, non-predicted touch points that come with the flag for "expecting force updates" should be treated as force predictions, not finalized data points. Using their force data for anything other than temporary on-screen display will cause trouble, unless you write your smoothing algorithm such that it's capable of backstopping and correcting the entire curve.
They're applying the corrections, but they're also applying way too much pressure smoothing (considering that you can't adjust it) and they're applying it preemptively on the uncorrected pressure data. This means that when you get bad (temporary) data from the API it's getting propagated into your whole stroke by the smoothing code and the effect won't be fixed even when the correction is processed. Basically it just shows a fundamental lack of understanding of the predictive functionality ("prediction" touches are clearly predictions, but so is any pressure data thats flagged as "expecting update.") You can ignore these "predictions" and only render the line when you get final data, but this will return you to Wacom/N-trig level of latency.
When you print the raw pressure data directly on screen with a large line width range you will see a lot of correction occurring (very fast but highly visible at large brush sizes) which is what Procreate is trying to avoid with the smoothing, but IMO it's much better to be able to get the raw pressure data even if it means being able to see the prediction tricks at work. The Pencil has impressively responsive pressure sensitivity, but we're not seeing it because everyone is trying to smooth out the data.
TL;DR Regular, non-predicted touch points that come with the flag for "expecting force updates" should be treated as force predictions, not finalized data points. Using their force data for anything other than temporary on-screen display will cause trouble, unless you write your smoothing algorithm such that it's capable of backstopping and correcting the entire curve.
