I decided that linear wasn't smooth enough, so master now does cubic
spline interpolation for the missing pressure and tilt information
after figuring out that we should just be using the motion events with
pressure+tilt as control points. Duh.
MyPaint now has to do more special treatment of transitions from zero
to nonzero pressure, and vice versa. I've been fairly carefully
testing:
* Fast handwriting with riggers and pens (deevad/soft-dip-pen and
deevad/brush)
- No dropped letters or strokes ☺
* Fast hairpin turns with the same, pen down only on the second leg.
- No hook-in artefacts noticed.
* CPU-lagged zoomed out scribbles with big brushes followed by quick
separate strokes all the way across the canvas
- All strokes render (eventually).
- No hook-outs or hook-ins noticed.
* Pressure responsiveness when making ribbons with very
pressure-sensitive brushes (Kaerhon v1's extreme_flat)
- Looks generally smooth at small sizes, and nice and responsive too.
- When made really big, and drawn fast there are fewer control
points to work with[1], so the pressure responsiveness does suffer.
- Not much we can do about this unfortunately, but the affected
sizes are fairly unrealistically big for most work.
* Absence of mouse button-release artefacts, and a nice tailoff for
non-tablet users.
and I *think* I have the balance right, but I'm not a real artist.
Feedback would be very welcome here, because having a good responsive
freehand mode is pretty much MyPaint's prime reason to exist.
[1] It's "interesting" that on some systems at least, the only thing
that might be gathering event data is the evhack code, if the CPU is
simultaneously burdened up with rendering a huge chunk of stroke data.
Not sure quite what to make of that, because it only happens for
fairly pathological cases (zoom all the way out and splash a big
watercolour brush all over the canvas when the view is tens of
thousands of pixels wide) but I'm happy that things seem to flow
fairly smoothly with the latest freehand hacks. About to go hands-off
with freehand now unless anyone spots any more bugs.
On 23 October 2013 11:12, Andrew Chadwick <[email protected]> wrote:
> People have reported success with the -wip branch, so I've pushed it
> to master for wider testing. I'm going with option 2 for filling in
> the missing pressure and tilt info; let me know if linear
> interpolation isn't smooth enough.
>
> On 21 October 2013 18:28, Andrew Chadwick <[email protected]> wrote:
>> Branch: https://gitorious.org/mypaint/achadwick-mypaint/commits/eventhack-wip
>> - this is the workaround for the GDK bug that artificially limits
>> input events to no more than the frame rate. It's coming along quite
>> nicely, I think, thanks to some really useful testing from various
>> keen people (thanks!)
>>
>> One problem remains: pressure (and tilt) fidelity is lacking. See the
>> attachment: that's a circular brush, but the staircase effect is very
>> evident. We have two options for dealing with this:
>>
>> 1. Duplicate GDK's processing of raw Xi2 axis/valuator info in the
>> guts of the filter; or
>>
>> 2. Linearly interpolate using the translated pressure and tilt info
>> available to us during processing of the events GDK lets registered
>> event handlers see.
>>
>> I'm in favour of option 2 myself, since it's less work, and less state
>> to maintain in what is a fragile, platform-specific, and hopefully
>> temporary hack. Would it be sufficient?
>>
>> --
>> Andrew Chadwick
>
>
>
> --
> Andrew Chadwick
--
Andrew Chadwick
_______________________________________________
Mypaint-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/mypaint-discuss
